Red Hat Bugzilla – Bug 243594
Firefox writes empty files into ntfs filesystem
Last modified: 2018-04-11 05:25:47 EDT
Description of problem:
Downloading a file into an ntfs (ntfs-3g) partition results in 0 byte file being
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start firefox
2. find a file to download
3. save it on ntfs filesystem
0 byte file gets saved
File is saved a full size
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
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
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
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
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
users, vendors, 3rd party evaluations saying these
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
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,
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
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
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.
> 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.