Re: Which NTFS features will be usable?
>Is anyone aware of which NTFS features will be accessible from Linux - or will
>translate into something Linux understands? For example links
NTFS links == UNIX hard links. NTFS can hard link directories (producing a DAG; I don't know if there is any checking for complete cycles in the default implementation). UNIX file systems can do the same, but UNIX traditionally crashes when this happens (based on experience with a malformed UNIX FS).
>and reparse points,
Called "symbolic links" in BSD style Unices. Windows Explorer "shortcuts" won't work; they are a feature of the Windows "ls" command which specially interprets files with the suffix ".lnk".
>file date/time granularity,
Broadly compatible at this point I believe; the LCD might still differ (I don't know) but it doesn't matter in practice at present because they both have sub-ms accuracy.
Nope, Linux canne do that captain. Remember that if you are using a particular file system as a native file system in Linux you are inherently constrained to using the OS'es identity mechanism. How well does Andrew work?:
fs/afs: 21402 lines of .c
>NTFS ACLs reversiblly mapping to Linux/Posix ACLs (so I could fix the damned things occasionally),
The thing about NTFS is that it is a superset of the (then) available file systems; it's just like reiser4, you can effectively do anything. So you can put Linux ACLs into it and you can get Windows ones out of it, but the question you are asking is how to map Windows ACLs into Linux ACLs. That's not a question for the file system; that's a question for *you* (assuming you are not a file system.)
> file name character restrictions (like colon ":"), alternate data streams (mentioned earlier), ...
It's a Multics style file system, not a UNIX style one. That is true. A file can contain multiple date streams; not alternate ones, multiple ones. Like a file in MacOS (which has two - more than one - multiple), unlike a file in UNIX which both rigorously and religiously insists that a file is just a single bag of bytes (albeit ordered; they never mention that!)
So? Linux can never be MacOS - it only has ONE stream in each file - and it can't be Multics and it can't be Windows. But colons? Seriously? It's convenient to have a *stream* delimiter that is distinct from a *path name* delimiter but that is an OS consideration. The syntax of a path name, including one with files that have multiple streams, is determined by the OS, not the file system. This is why the ADFS file system works in Linux - it does *not* use the RISC OS directory separator! Likewise try using "\" as a directory separator in Linux when you have a FAT file system mounted.
If Linus wanted to permit file**/**stream he could.