FAT, NTFS, CIFS and DOS attributes

[H. Peter Anvin]

tridge at samba.org wrote:
> 
> I think you'll find that all users of dos attributes on Linux will
> have very similar needs to Samba, and will want these things grouped
> together. For example:
> 
>  - backup/restore apps will want to backup/restore these attributes as
>    lumps
>  - wine implements essentially the same APIs as Samba, just in a
>    different form, and so tends to get the same groupings of
>    attributes get/set calls that Samba does (the SMB protocol is to a
>    large degree a on-the-wire version of Win32).
> 
> Are there any other significant users of DOS attributes on Linux that
> want something different?
> 

I don't know, but it certainly doesn't match my application (which is 
pretty simple... needing to frob DOS attribute bits while writing DOS 
files) or expectation thereof... plus it's not very unixy :-/

More or less what you seem to want is an ioctl() that takes a mask of 
what to write, similar to the way notify_change() works inside the 
kernel.  This is a legitimate API, but it requires knowledge of the 
internals, and isn't setxattr().  The big thing here is the need for a mask.

Of course, one way one can do this is to expose user.dos.attrib or 
something like that as a synthesized block form of these, and still have 
separate system.* xattrs that control the individual options on the 
filesystems which actually store this stuff.

I certainly see why *you* want it, but it still seems to me to be bad 
interface design for anything other than backup and file repository 
programs.  Also see my previous note about endianness of structures 
carried from place to place.

At this point I think I'm going to let my ioctl() patch stand as-is, 
solving the immediate problem, and let people who are more directly 
affected delve into this particular morass.

	-hpa