
Thread beginning with comment 199375
Member since:

And READ the limitations of this.

Yes, it can read and write NTFS files - maybe 50% of the time.

The other 50% it "refuses to perform the action".


This is not usable if that is the case. I have not tested it yet precisely because I am not going to risk a Windows partition holding my OS to a tool that refuses to function 50% of the time.

Yes, they SAY that by doing this they avoid almost all possibility of corruption. That IS good.

What would be better is if it worked at least 90-98% of the time - not 50%.

When people report that they can copy and paste an entire directory of maybe 500 or a thousand image files between NTFS partitions with absolutely no problems CONSISTENTLY, then I'll try it.

Reply Score: 0

cyclops Member since:

"And READ the limitations of this."

Post your link. I have searched and found nothing.

Show me!!!!

Reply Parent Score: 4

AdamW Member since:

Um, where do you see that?

I used ntfs-3g to extract several gigabytes of zip files to an NTFS partition the other week. No problem at all.

Reply Parent Score: 2

HK47 Member since:

i've used ntfs-3g pretty much since its first public release on Kanotix (and now Sidux), and i've never experienced any serious problems with it. and i used it HEAVILY since my main data storage partition is in NTFS. it never "refused to perform the action" through all the large archive extractions and torrent downloads that i put it through. and not a single file corruption.

i only encountered a problem when i accidentally created a folder with a name ending with ".", which Windows doesn't like. going back to linux and renaming the folder solved the problem. also, during heavy read/write operations (such as with torrents), CPU usage can get pretty high sometimes.

AFAIK the only real limitation of ntfs-3g is that it doesn't support compressed and/or encrypted ntfs wolumes.

Reply Parent Score: 2

szaka Member since:

The article discusses the NTFS-3G driver (, not the Linux-NTFS one ( You looked at and quoted from the wrong project.

Reply Parent Score: 5

richardstevenhack Member since:

I may have conflated the two projects with that specific item, but on the other hand look at the change history over the last couple of months. While he's fixing bugs fast, there ARE SIGNIFICANT BUGS! No, thanks, I'll wait until I see maintenance releases only.

Version 0.20070102-BETA:

* fix: writing large files could be very slow
* fix: writing several files at the same time could be very slow
* fix: writing at several places into a file at the same time could be very slow
* fix: invalid argument error when writing randomly into sparse files

Version 0.20061218-BETA:

* fix: heavy memory usage with sparse files (p2p, bittorrent client problems)
* fix: inode number wasn't filled in the dirent structures (CVS, getcwd, gnulib problems)
* fix: 2-8% speed increase due to using pread/pwrite instead of lseek+read/write
* fix: fuse 2.6.x kernel module detection wasn't reliable

Version 0.20061212-BETA:

* fix: directories were inaccessible on Windows if the cluster size was bigger than 4kB
* fix: static linking failed with FUSE 2.6.0
* fix: 'make install' failed if ldconfig wasn't in the $PATH
* change: more verbose error reporting, explanations, hints for solutions

Version 0.20061115-BETA:

* fix: unmount was unsafe for removable devices
* fix: the code wasn't endian safe
* fix: mount arguments were omitted on the 2nd fuse mount attempt
* new: FUSE 2.6.0 is required to ensure maximum reliability
* new: bmap() implemented: safe swap file support, LILO bootability
* change: the file system type is 'fuseblk' instead of 'fuse' for block devices

Version 0.20061031-BETA:

* fix: unmount was asynchronous; full fix requires FUSE 2.6.0 as well
* fix: mount was denied if $MFTMirr was too small
* fix: option parsing was incorrect if there was no space between name & argument
* change: new software versioning


* fix: file creation at disk-full may lead to i/o errors
* fix: statistic of inodes and free inodes was incorrect (df -i)
* fix: the 'umask' option wasn't always parsed as an octal number
* fix: "too long filename" handling wasn't POSIX compliant
* fix: mount was denied if $MFTMirr had unused garbage at the file end


* fix: rename was always denied if the target file or directory existed
* fix: renaming like 'foo' -> 'FOO' was denied in the WIN32 namespace
* fix: fuse kernel module is automatically loaded, no need for config
* fix: verbose mount error messages with hints for solutions
* fix: compilation failed with gcc 2.96
* change: top request: full read-write access to everybody by default
* change: file lookups are always case-sensitive


* fix: case-insensitive directory rename to itself may failed
* fix: some regular files weren't accessible on Linux
* fix: files created on Linux may not had enough permissions on Windows


* fix: directory couldn't be renamed if it had both WIN32 and DOS name
* fix: collision with ntfsprogs header files


* fix: improved large file write performance
* fix: better consistency if NTFS wasn't cleanly unmounted
* fix: write(2) may created holes
* fix: show mounted device names instead of /dev/fuse


* first ntfs-3g BETA release

Reply Parent Score: 1