Description of problem: Downloading a file into an ntfs (ntfs-3g) partition results in 0 byte file being written. Version-Release number of selected component (if applicable): firefox-2.0.0.4-2.fc7 How reproducible: always Steps to Reproduce: 1. start firefox 2. find a file to download 3. save it on ntfs filesystem Actual results: 0 byte file gets saved Expected results: File is saved a full size Additional info: gedit saves files to ntfs fine. Firefox saves files into ext3 fine. They can be then copied to ntfs without problems.
It occasionally does this on FAT32 partition as well.
This could be a duplicate or related to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=242448 I do remember some versions of Firefox having problems saving files to FAT32 and NTFS. Perhaps this one: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/65164
NTFS linux drivers are unrealiable and highly experimental (they are good in RO mode, but not RW; the problem is of course not in the creators of the driver, but in the undocumented and perpetually changing state of NTFS). We that it is more appropriate to let this bug be resolved upstream (upstream bugs https://bugzilla.mozilla.org/show_bug.cgi?id=382157 and possibly also https://bugzilla.mozilla.org/show_bug.cgi?id=336113). Red Hat will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates. Thank you for the bug report.
> NTFS linux drivers are unrealiable and highly experimental (they are good in RO > mode, but not RW; the problem is of course not in the creators of the driver, Matej: I'm the lead developer of ntfs-3g and our driver is definitely not experimental but stable. We are also not aware of and were not reported unreliability problems in ntfs-3g. If you have proof for your claims then please immediately let us know because that would be our fault and will fix them urgently. You can find here how we test the driver: http://ntfs-3g.org/quality.html You can also make your own tests, no Windows or NTFS partition required, a simple Linux computer is enough: http://ntfs-3g.org/quality.html#howtotest > but in the undocumented and perpetually changing state of NTFS). We do know the NTFS specification and the fundamental things required for a stable write driver hasn't changed during the last 7 years we are working on ntfs-3g.
Szabolcs, sorry I really didn't want to talk badly about you (hopefully at least that is obvious from my previous comment) and about your effort. Not being a kernel hacker myself, I got this impression from some chatting with author of Captive (http://www.jankratochvil.net/project/captive/) who seemed to be quite hopeless about prospects of NTFS RW drivers. If he was wrong and you are able to make it work, even better!
Matej: Captive NTFS is indeed unreliable. One can make it crash and lose data running e.g. "for i in $(seq 1 200) ; do touch $i ; done" or writing a file over 1 GB, etc. We have tried to compare the NTFS implementations on Linux but we've found Captive to be unusable for evaluation because it couldn't pass most functionality tests without crashing. It's also unbearable slow, something like 50-300x more than ntfs-3g. But you can't really compare the two. Captive was a one year wrapper project around the Windows NTFS driver but the open source driver has been worked on dozens of people for twelve years and we didn't develop only a read/write driver but a whole collection of NTFS utilities (mkfs, resize, clone, image, backup, undelete, fsck, dbg, etc) which are reliably interoperate with the Microsoft NTFS drivers, tools for many years. Today I'm still getting congratulations emails from those who worked on this to be a reality over a decade ago! NTFS can't really be compared with other Linux file systems because it's so much more complex. Jan isn't familiar with NTFS, he was working on emulation, not pure implementation of a specification for smooth interoperability. He says you can't reliably reverse engineer things but that's obviously untrue. It's only a matter of time and willingness.
The misunderstanding here is what means "unrealiable". * Captive-NTFS commonly drops the user written data with appropriate warning message and without corrupting the drive metadata. * Linux-NTFS loses the data and corrupts the drive without any message. On the other hand there were reports on Captive-NTFS also corrupting the drive. It is true the original Microsoft driver also sometimes corrupts the drive. The only recommendation can be to drop MS-Windows and convert the drive to ext3.
> The misunderstanding here is what means "unrealiable". For me it means passing at least all of the quality tests on http://ntfs-3g.org/quality.html#testmethods users, vendors, 3rd party evaluations saying these http://ntfs-3g.org/quality.html#testimonials being included in or available for about 100 Linux distributions and used widely with satisfaction on daily bases. > * Captive-NTFS commonly drops the user written data with appropriate warning > message and without corrupting the drive metadata. Captive NTFS is losing entire files, not one or two but sometimes many dozens. It lose not only user data but also metadata (see e.g. the 'for' test where typically most previously created files get lost). Captive fails most of the tests at http://ntfs-3g.org/quality.html#testmethods with a crash and data loss. > * Linux-NTFS loses the data and corrupts the drive without any message. NTFS-3G is not Linux-NTFS. They are two different projects. In fact, NTFS-3G had to be forked from Linux-NTFS because that was the only feasible way we have seen to produce a stable NTFS driver. We've solved reliability problems which we identified systematical by our test and interoperability suites, or what we have debugged with intense community help.
(In reply to comment #8) > with a crash and data loss. No - "reported refusal of the requested operation" instead. On one hand it never made sense to argue about it with you, I was never sure if you knowingly refuse to accept this difference or you just never understood it. Anyway even Microsoft NTFS is inacceptably unreliable so I believe this discussion does not make much sense at all. If any OS is reliable at all.
> No - "reported refusal of the requested operation" instead. > > On one hand it never made sense to argue about it with you, I was never sure if > you knowingly refuse to accept this difference or you just never understood it. Here is an example, User creates file A, Captive reports success User creates file B, Captive reports success User creates file C, Captive reports success User creates file D, Captive reports success User creates file E, Captive says "refusal of the requested operation" then Captive exits and loses the entire A, B, C and D files which won't be available to the user anymore. This is what I mean Captive crashes and loses files (A, B, C and D). The inability to create file E resulted halting the driver and the disappearances of the A, B, C and D files. How does this work in NTFS-3G? The relevant errno is reported to the user via the syscall, the driver keeps running normally and the A, B, C and D files remain intact.
At the point E it had written to the syslog: Filesystem crash broke dirty object: A Filesystem crash broke dirty object: B Filesystem crash broke dirty object: C Filesystem crash broke dirty object: D Filesystem crash broke dirty object: E Right? While I understand it is inconvenient for the user the important fact is that the drive remains consistent (intact if only these operations were made). (Also I hope you tested it either with captive-cmdline(1) or GnomeVFS interfaces; the Linux kernel FUSE one is unsupported/broken due to the kernel/FUSE.) It would be nice if it would work your described way for NTFS-3G. From the bugreports I know from your mailing list it works as: A, B, C, D and E files get written but the metadata modified by the file E get corrupted (as reported by later CHKDSK.EXE) with no message to the user. And Captive-NTFS in its current form (==the initial release time) was only the basic functionality with the goal of never corrupting the drives enabling the incremental extension of the functionality to have better (99.999%) write success probability. Due to various reasons (such as I never got a single patch for it) it was never further developed. Still I found it as a proof of the broken developed model of Linux-NTFS/NTFS-3G if a one manyear could provide better functionality (metadata write capability at all, and even safer than Linux-NTFS/NTFS-3G nowadays) than the project with your reported "worked on dozens of people for twelve years" above. Anyway the F/OSS development shows that the designs and technical reasons make no sense, important is the willingness of the developers to put their time to. And I hope you enjoy working on Linux-NTFS/NTFS-3G - that's what matters, doesn't it? VHS really was not better than Betamax (FYI Betamax was also a video tape). ;-)
> At the point E it had written to the syslog: > Filesystem crash broke dirty object: A > Filesystem crash broke dirty object: B > Filesystem crash broke dirty object: C > Filesystem crash broke dirty object: D > Filesystem crash broke dirty object: E > Right? People don't read syslog. They expect that the application will report an error if a file system operation fails and the driver keeps functioning. But in such cases Captive just silently crashes and the NTFS volume disappears. A stable file system driver shouldn't stop working just because it meets an unimplemented or unexpected scenario. > It would be nice if it would work your described way for NTFS-3G. It does. > From the bugreports I know from your mailing list it works as: A, B, C, D > and E files get written but the metadata modified by the file E get > corrupted (as reported by later CHKDSK.EXE) with no message to the user. You won't be able to find such message on the NTFS-3G mailing list because there wasn't such email, and more importantly this is not how the driver works. File operations are ordered, in-memory metadata changes which are only flushed to disk if everything succeeds. It's like softupdate of FFS. > Still I found it as a proof of the broken developed model of > Linux-NTFS/NTFS-3G if a one manyear could provide better functionality > (metadata write capability at all, and even safer than Linux-NTFS/NTFS-3G > nowadays) than the project with your reported "worked on dozens of people > for twelve years" above. Based on my evaluation and users' feedbacks who used both, I think Captive is on a prototype level and far from production quality. What we experience by every day use and get feedbacks is that NTFS-3G is much more reliable (do your own tests: http://ntfs-3g.org/quality.html#howtotest), much more faster, and has more functionality. It has been even ported to FreeBSD, OS X, NetBSD, Haiku, BeOS, DOS, ia-64, ARM, MIPS, PowerPC, Sparc, etc. > Anyway the F/OSS development shows that the designs and technical reasons make > no sense, important is the willingness of the developers to put their time to. Wrapping proprietary binaries in a way which is barely usable is not something F/OSS developers get very exciting about ;-) It's also important to note that the open source NTFS driver is a completely voluntary project, and a real man year work (what you did as a thesis) here takes 3-4 years since we can work on it only in our spare time.