FAT, NTFS, CIFS and DOS attributes

[Steven French]

These are very interesting questions and not just for interop with files 
created by other operating systems  (locally) via NTFS or VFAT or 
(remotely) via CIFS or NFSv4 etc.  These features have some value 
independent of interoperability and storing all of these (which in effect 
are inode metatdata) as free form xattrs may not be ideal.
        1) How to recognize that a file is
                sparse
                encrypted
                compressed
        2) How to add additional "reparse info" that is useful for certain 
drivers (and for handling the interesting form of symlink alluded to in 
the note)

There are other interesting inode metadata representation/API issues - 
returning quotas via the kernel VFS is not really for network filesystems 
(and it is not obvious that xattrs are the best solution for that).

For sparse files, I don't mind it being a "read only" attribute (ie you 
can not set the sparse bit, it is silently ignored).   But isn't any file 
that has a allocation size that is smaller than its end of file (file 
size) by definition sparse?  So would it matter for an app to have a 
"hint" that a file is sparse?   Can you really create NTFS files (in that 
other OS) with the sparse flag (does it really do anything differently if 
you create with that flag)?

For encrypted files, Mike Halcrow et al and the Linux Encrypted File 
System are interesting but it is not clear to me whether they will end up 
keeping xattrs as a way of recognizing that a file is encrypted or not.

There are files which are compressed in NTFS on servers and it would be 
useful for the client application or VFS to know this so it could be 
decompressed before being read but I don't know an easy way to do this at 
this point and it needs more investigation.

For reparse points, only the pseudo-symlink was something I recognize in 
the cifs code but that code has been disabled since you can't follow those 
links on the client (they have windows drive letters in them in most 
cases).
Services for Unix (SFU) also handles symlinks and device files and other 
Unix-centric inode info via the EAs (OS/2 extended attributes) so I need 
to add code to recognize those at some point so I can return symlink info 
for symlinks, device files etc created on such servers.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com



Nicholas Miell <nmiell at comcast.net> 
01/04/2005 07:12 PM

To
Anton Altaparmakov <aia21 at cam.ac.uk>
cc
"H. Peter Anvin" <hpa at zytor.com>, sfrench at samba.org, ntfs-dev 
<linux-ntfs-dev at lists.sourceforge.net>, samba-technical at lists.samba.org, 
hirofumi at mail.parknet.co.jp, lkml <linux-kernel at vger.kernel.org>
Subject
Re: FAT, NTFS, CIFS and DOS attributes






On Tue, 2005-01-04 at 16:48 -0800, Nicholas Miell wrote:

> [ Note to audience: the following is a long (and largely irrelevant to
> the subject) discussion of how NTFS could implement reparse points and
> encryption on Linux. Feel free to ignore it. ]

Sorry for the reply to my own message, but I forget to mention in the
original that the right thing to do for the Encrypted and Reparse bits
may be just be to silently discard them and not support the manipulation
of these rather esoteric NTFS features through a general API at all.

-- 
Nicholas Miell <nmiell at comcast.net>