• Wiki Home
• Forum
• Search
• ntfsprogs manpages

• What is NTFS?
• How can I access NTFS?
  • The kernel driver
  • Userspace driver (ntfsmount)
  • Userspace tools (ntfsprogs)
• Current project status
• Other Documentation

• Downloads
• Development
• RedHat/Fedora
• About us

~~CLOUD:30~~

The roadmap was first published in the Linux-NTFS-dev mailing list on May 17, 2004 by Anton Altaparmakov. It was last edited at May 14, 2006 by Yuval Fledel to reflect current state.

Orginal archive link: http://sourceforge.net/mailarchive/forum.php?thread_id=4410614&forum_id=2697

I reserve the right to turn the roadmap on its head or to throw it away and do it completely differently but with some luck things will happen roughly like this… (-;

Note that I am not taking into account that other people might contribute / work on specific features and submit them to me which could obviously cause some feature(s) to be implemented in a different order to what the roadmap specifies but this is how I, were no one to contribute, am likely to proceed. Any contributions would be a bonus on top of this and are of course both strongly encouraged and welcomed! (-:

Current release 2.1.27/kernel 2.6.16

• Basic read-only is complete:
  • this includes:
    • access to normal files.
    • access to compressed files and directories.
    • loopback mounting of normal/compressed files.
    • NFS exporting of mounted volume (2.6 kernels only).
    • hard links.
  • but this does not include:
    • access to encrypted files.
    • ACLs ($Secure).
    • quota ($Quota).
    • symlinks and DFS/HSM stuff ($Reparse).
    • access to named streams.
    • access to extended attributes (EAs).

The above missing read-only features will be implemented but for me personally they are very low priority. Obviously all of these missing read-only features are also missing from the supported read-write features and they are going to be implemented only after their read-only counterparts are implemented.

Another feature, this one is read-write, that is missing is journalling. This is not planned until everything else is implemented. At the moment, the only journalling related feature that is implemented is that the journal is checked at read-write (re)mount time and if it is obviously clean the mount is allowed and if we cannot detemine that the journal is clean the mount is aborted or forced into a read-only mount depending on the mount option “on_errors”.

• Basic truncating/extending/overwrite is partially complete:
  • this includes:
    • writing to normal files.
    • access/modified time updates.
    • Shrink/enlarge files.
  • but this does not include:
    • writing to compressed files.
• Technical completed abilities:
  • dirty and then to write dirty mft records to disk.
  • mark inodes dirty and to write them out on request.
  • (de)allocate clusters.
  • convert resident attributes to non-resident ones.
  • Implement setting the volume dirty bit in the volume flags on read-write (re)mount and clear it again on clean umount. That way a crash would cause chkdsk to be run on the volume when Windows mounts it and hopefully this would correct any problems/inconsistencies.
• Other write features that are not implemented yet at all:
  • Extending a file if attribute list is required.
  • mmap(2)
  • Creating sparse regions.
  • creating files/directories.
  • deleting files/directories.
  • creating hard links.
  • creating sym links.
  • removing sym links.

• convert non-resident attributes to resident ones (probably will never be be done since the driver restructuring required to support it is just not worth it).
• Write support for attribute list attributes so that it is possible to resize all normal files, including very fragmented ones.
  • This requires the ability to:
    • work with the attribute list attribute, including:
      • remove attribute list attribute entry.
      • modify attribute list attribute entry.
      • add attribute list attribute entry.
      • remove the attribute list attribute.
      • create the attribute list attribute.
    • deallocate mft records.
    • allocate mft records.
    • split attributes into extents, including:
      • split run list into fragments.
      • size fragments appropriately for the available space.
      • compress run list fragments into mapping pair arrays.
    • coalesce attribute extents.

• Write support for compressed files. (This might well end up moving up or down the list as I consider it more of a “cool” feature than a high priority item. It may well even drop to the second “low priority” list…)

* Support for file/directory deletion (includes hard link removal).

• This requires the ability to:
  • remove entries from the index root and allocation attributes.
  • deallocate index allocation blocks.
  • truncate index allocation attribute and bitmap attribute.
  • removal of index allocation attribute and bitmap attribure.

• Support for file/directory creation. This requires the ability to:
  • add entries to the index root and allocation attributes.
  • allocate index allocation blocks.
  • extend index allocation attribute and bitmap attribute.
  • create index allocation attribute and bitmap attribute.

• Support creating hard links.

• Support rename.

At this point we have complete basic read-write support and can start implementing the more fancy features (i.e. the ones I described above as being very low priority for me). At present the likely order of me implementing these features is something like (high-level only, no details):

• create and remove symbolic links ($Reparse).
• special files (character and block devices, sockets, etc…).
• ACLs ($Secure, including user specified mapping of UNIX ids to SIDs).
• Quota ($Quota).
• Named streams.
• Extended attributes.
• Encrypted files (requires user supplied private keys).
• DFS/HSM stuff ($Reparse).
• User space journalling ($UsnJrnl).
• Meta data journalling ($LogFile).

I don't think I have missed any featues but if I have then either apply common sense as to where I am likely to fit them in or ask.