Re: FAT, NTFS, CIFS and DOS attributes

From: H. Peter Anvin
Date: Mon Jan 03 2005 - 20:18:52 EST


tridge@xxxxxxxxx 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/