Risk of Writing to NTFS Volumes

Ouattara Oumar Aziz wattazoum at gmail.com
Wed Sep 13 19:12:58 UTC 2006

Ouattara Oumar Aziz a écrit :
> Sameera Shaakunthala a écrit :
>> Hello,
>> I heard that Dieter told that writing on NTFS volumes is still 
>> experimental and there is a risk of doing this.
>> What will actually happen in the background if I write to a NTFS volume? 
>> What is the risk?
>> Sameera Shaakunthala

More Infos (I am so Kind :) )


Recently added or updated items are always on the top.

Problem:    File modification times aren't always updated.
Status:     High priority work.

Problem:    VMware segfaults during startup.
Answer:     By default VMware tries to use shared writable mmap for paging
             files but it can't detect that it's not yet supported.
Workaround: Set "mainMem.useNamedFile=FALSE" in your .vmx file. That will
	    disable these paging files and VMware will work fine.
Status:     Priority, hard work.

Problem:    Writing large files sometimes can be very slow.
Answer:     The cluster allocator and the mapping pairs updater algorithms
	    aren't efficient for large files on very fragmented volumes.
Workaround: Try to defragment your NTFS, it may help.
Status:     Priority work.

Problem:    Why doesn't the driver work on 64-bit and big-endian systems?
Answer:     The code is 64-bit ready and almost fully endian safe, however
             unfortunately we are unable to validate the functionality and
             keep ensuring correctness for the future due to lack of target

Problem:    "Directory not empty" message when deleting "empty" 
Answer:     If locale isn't set correctly then glibc can't convert
	    some filenames, so they aren't visible and the directory
	    indeed isn't empty. Occurs very rarely.
Workaround: Set your locale properly according to the used characters
Status:     High priority work.

Problem:    "Operation not supported" message when creating a file:
Answer:     This is a controlled refusal of file creation which can happen
             when there are already about 100,000 files on the NTFS and the
             MFT needs to be extended in a way which isn't implemented yet.
Workaround: Delete files then you can create new ones.
Status:     High priority work.

Problem:    "Operation not supported" message when deleting a file:
Answer:     The support for certain very-very rare directory update
             operations weren't fully tested yet, so they are not
             included in the release. This is so rare that you probably
	    will never see it ;-)
Workaround: Delete or create other files in the same directory until you
	    can remove the file you originally wanted.
Status:     High priority work.

Problem:    Windows chkdsk complains about free space being marked in use.
Answer:     chkdsk sometimes optimizes the NTFS layout and later finds
             its own bugs (e.g. when index root attributes are moved from
             extent mft records to the base one). This is not a problem
	    with ntfs-3g.
Workaround: No need, it's a chkdsk bug and it fixes itself.
Status:     Low priority work: we will optimize our algorithms too.

Problem:    Windows chkdsk reports the below messages (N is a number).
	    Cleaning up N unused index entries from index $SII of file 0x9.
	    Cleaning up N unused index entries from index $SDH of file 0x9.
	    Cleaning up N unused security descriptors.
Answer:     These messages are part of an optimization process which is
	    completely independent of ntfs-3g. Nothing to worry about them.
Workaround: No need.
Status:     Nothing to do.

Problem:    Windows chkdsk may report minor inconsistency.
Answer:     The allocation size of sparse files isn't set always correctly.
Workaround: No need.
Status:     Normal priority work.

Problem:    Why ntfs-3g CPU usage is always 100%?
Answer:     You have some application running which inefficiently "polls"
             for file modification events.
Workaround: Identify the software and try to upgrade it.
Status:     Normal priority work: we also intend to improve significantly
             our CPU usage for such cases.

More information about the ubuntu-users mailing list