Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at

Bug 210840

Summary: Review Request: ntfs-3g - Linux NTFS userspace driver
Product: [Fedora] Fedora Reporter: Tom "spot" Callaway <tcallawa>
Component: Package ReviewAssignee: Jason Tibbitts <j>
Status: CLOSED RAWHIDE QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: j, pertusus
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-21 21:49:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 163779    

Description Tom "spot" Callaway 2006-10-16 03:15:18 UTC
Spec URL:
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.

Comment 1 Jason Tibbitts 2006-10-16 05:22:37 UTC
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.

Comment 2 Jason Tibbitts 2006-10-16 06:15:18 UTC
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
of 0.1.%{buildrev}%{?dist}.

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:
   6382355a472c96e0ed9f4f62d4d9496f  ntfs-3g-20070920-BETA.tgz
? 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.

Comment 3 Jochen Schmitt 2006-10-16 16:15:49 UTC
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.

Comment 4 Tom "spot" Callaway 2006-10-16 19:23:48 UTC
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.

Comment 5 Jason Tibbitts 2006-10-16 20:02:38 UTC
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
for me.

Comment 6 Tom "spot" Callaway 2006-10-16 20:21:31 UTC
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


Comment 7 Jason Tibbitts 2006-10-16 20:36:58 UTC
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
it, too.)  

> 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.

Comment 8 Patrice Dumas 2006-10-21 09:09:09 UTC
NTFS should be removed from the forbidden item in packaging
guidelines before this can be accepted?

Comment 9 Tom "spot" Callaway 2006-10-21 21:49:58 UTC
Updated ForbiddenItems to remove NTFS, since OIN has us covered on that one.

Packages are built and in repo, closing.

Comment 10 Dawid Gajownik 2006-10-22 11:47:55 UTC
Just for your information, it does not work with SElinux enabled (bug 211767).