Re: FAT, NTFS, CIFS and DOS attributes

[tridge]

 > The slightly stronger reason is basically the same reason why we don't 
 > stuff a bunch of things into a struct stat and call a single system call 
 > to change a bunch of attributes

yes, and if we want this to be a good API then we'd use something like
a bitmask to indicate what fields to update so we can update them in
groups in a raceless fashion, but that would require that the kernel
understand the internals of these structures. I didn't have that
luxury, so I grouped them in the way that best matched the common use
of the attributes.

 > you don't want to have to change them all every time, and by
 > putting them all in the same structure that's your only option,
 > since setxattr() doesn't allow you to mask and merge.

can you tell me who you imagining will be using these attributes apart
from Samba, Wine and backup/restore apps? 

 > 
 > Incidentally, the document you pointed me to wasn't clear on the 
 > endianness convention.

It's little-endian NDR. For a full description of NDR in all its gory
details see http://www.opengroup.org/onlinepubs/9629399/chap14.htm

NDR seems like overkill at first, until you start to look at security
descriptors. They are very complex beasts, and using IDL/NDR makes it
much easier (in fact, security descriptors need some minor
enhancements to NDR to encode them the same way windows does).

Cheers, Tridge
-
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/