Red Hat Bugzilla – Bug 210840
Review Request: ntfs-3g - Linux NTFS userspace driver
Last modified: 2007-11-30 17:11:45 EST
Spec URL: http://www.auroralinux.org/people/spot/review/ntfs-3g.spec
SRPM URL: http://www.auroralinux.org/people/spot/review/ntfs-3g-0.1.20070920-1.fc6.src.rpm
The ntfs-3g driver is an open source, GPL licensed, third generation
Linux NTFS driver. It provides full read-write access to NTFS, excluding
access to encrypted files, writing compressed files, changing file
ownership, access right.
Technically it’s based on and a major improvement to the third
generation Linux NTFS driver, ntfsmount. The improvements include
functionality, quality and performance enhancements.
ntfs-3g features are being merged to ntfsmount. In the meanwhile,
ntfs-3g is currently the only free, as in either speech or beer, NTFS
driver for Linux that supports unlimited file creation and deletion.
This is what is known as "forcing the issue". The NTFS functionality has been shipped in source code format as part of Red Hat Linux and Fedora Core for several YEARS. The kernel, which shipped this code, is under the protection of the Open Inventions Network. Add all of that together, and NTFS should be safe for Fedora. This package actually works very well, and provides extremely valuable functionality for dual boot users, and users weaning off other OSes.
I can do a basic review for form, but I have no way to test this since I have no
NTFS in sight and there's no mkfs.ntfs included in this package.
OK, this builds and installs fine in mock on x86_64 rawhide. rpmlint just says:
W: ntfs-3g-devel no-documentation
which is OK as there's no developer documentation in the tarball.
One wonders why the date in the version is one year off.
I know you wrote the naming guidelines so perhaps I'm misreading, but I'd
interpret this as a prerelease package and give it a version of 0 and a release
Currently the main executable installs into /usr/bin and a symlink is placed
into /sbin. I wonder if that should go the other way around. (Although I guess
it would indeed be insane to try to put /usr on NTFS.) A quick check shows no
symlinks in /sbin that point outside of /sbin on the systems I have handy.
* source files match upstream:
? package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* dist tag is present.
* build root is correct.
* license field matches the actual license.
* license is open source-compatible. License text included in package.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (development, x86_64).
* package installs properly
* debuginfo package looks complete.
* rpmlint has only acceptable complaints.
* final provides and requires are sane:
ntfs-3g = 0.1.20070920-1.fc6
ntfs-3g-devel = 0.1.20070920-1.fc6
ntfs-3g = 0.1.20070920-1.fc6
! %check is not present; no test suite upstream. I am not able to test this
package as I have no access to NTFS.
* shared libraries are present; ldconfig is called properly.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* scriptlets are OK (standard ldconfig call)
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers are in the -devel subpackage.
* unversioned .so file is in the -devel subpackage.
* no pkgconfig files.
* no libtool .la droppings.
Guestion: What is the legale state of inclusssion of ntfs into Fedora Extras.
As far as I known, the kernel of fedora is compiled without NTFs support becouse
of legal issues.
But if that not be a issue now, it will be nice if fedora may ship the kernel
with compiled NTFS support.
My statement is that because the kernel ships with NTFS source code (whether or
not it is compiled is immaterial), and the kernel is protected on patents from
OIN, then the ntfs userspace implementation which does all of the same things as
the kernel code is also protected. I'm challenging the Fedora Board to step up here.
Either OIN protects us and we're ok, or it doesn't.
And in any case, it's far easier to get a userspace filesystem package into
extras than it is to get an updated, fully AQ'd kernel out to core.
So, spot, any comment on the two issues I found? And is anyone willing to test
this out? Alternately, I guess I could get a friend to NTFS-format a USB stick
You're right. I didn't follow my own naming guidelines. Shame on me. :)
Seems like it is better to be safe with the /sbin/ /usr/bin scenario and make it
a copy rather than a symlink, so thats what I did. Also fixed the
New SPEC: http://www.auroralinux.org/people/spot/review/ntfs-3g.spec
OK, I'm testing (the previous release, as I already had it built).
I installed it and fuse-libs came in to satisfy the dependency, and went to
mount an NTFS-formatted USB stick I got from a friend. (Bit of a pain to make
> s mount -t ntfs-3g /dev/sda1 /mnt
fuse: failed to exec fusermount: No such file or directory
Failed to mount NTFSUnmounting /dev/sda1 (Test)
So it looks like there needs to be a dependency on fuse in there. After
installing fuse, things seem to work great; I can read existing data, rename
files, create new files and delete stuff.
The default permissions here are a bit wide-open, which may be troubling, but
otherwise things are fine:
> grep sda /proc/mounts
/dev/sda1 /mnt fuse rw,nosuid,nodev,noatime,user_id=0,group_id=0,allow_other 0 0
Other than that missing dependency on fuse, I'd say everything is fine. I'll go
ahead and approve this and you can add it if you do decide to check this in.
NTFS should be removed from the forbidden item in packaging
guidelines before this can be accepted?
Updated ForbiddenItems to remove NTFS, since OIN has us covered on that one.
Packages are built and in repo, closing.
Just for your information, it does not work with SElinux enabled (bug 211767).