Windows File Attributes

[Andrew Bartlett]

On Thu, 2003-11-13 at 10:10, Ravi Wijayaratne wrote:
> 	Hi All
> 
> 	Currently we are encoding the windows Hidden, Read Only, Archive and
> System file attributes in 
> 	read, write, execute permissions of user, group and other id
> entities. Though the above encoding
> 	is quite cleverly done to avoid serious effects of overloading the
> effective permissions we have
> 	determined that it causes confusion when representing the ACLs.
> Furthermore since Samba 
> 	now supports automatic ACL propagation, the above permissions tend
> to vanish when the user,
> 	group, mask and other ACEs are set or unset by way of propagating
> permissions.
> 
> 	As an alternative we propose that the Windows file attributes be
> stored as an extended native file
> 	system attribute. Though the solution is fairly straightforward
> there are several pitfalls that one needs
> 	to be aware of in such an exercise.
> 
> 	The archive bit is set whenever the file is opened for
> modifications. It will affect performance if we
> 	have to write to the extended file attribute for each file that is
> created or opened for modification. From our 
> 	Netbench benchmarks we see that there is about a 30-40% degradation
> of performance if the Archive
> 	bit is set per file creation or modification. Therefore we propose
> that for files, the absence of the 
> 	extended attribute be encoded as the archive bit being set. For
> directories the archive bit is not
> 	set by default. Therefore we propose that the encoding be reversed
> for directories. With this strategy
> 	we see that there is only a 3-6% drop in performance well within the
> error deviation of Netbench.

How much do you pay to have a consistent approach?  Can we get some hard
numbers on all of these, particularly for a file-system level
implementation?  (Given that the archive bit really should apply to
unix/NFS/afs modifications too).

A good design should pay attention to performance, but similarly an
interface should pay attention to good interface design.  I could argue
that the FS should create the archive bit the right way around
'transparently', and that how it appears to userspace is meaningless in
performance.

> 	Now one may quite validly argue that we set different extended
> attributes per Windows file attribute 
> 	and encode the presence and the absence of each attribute as the bit
> being set or unset or vise versa. 
> 	This approach may see better performance than the above approach.
> However many backup/restore 
> 	programs do not handle extended attributes. Therefore in the case of
> a backup and restore operation 
> 	the Windows File System attributes are lost. Many file system
> vendors go the distance to write hooks 
> 	to backup the extended attributes. Having many extended attributes
> will greatly complicate their job.

This is a lame argument.  I suggest that having a single attribute
greatly complicates that task of atomically setting the individual bits,
and makes it less intuitive for applications such as wine/user
interfaces etc.  

A backup vendor should backup all extended attributes, or follow our
published spec on the matter.  At least give us some performance numbers
on it.

> 	I have attached a patch which is similar to our implementation. I
> would very much appreciate your feed
> 	back. 

Indentation, coding style (or compleate lack thereof) aside, it looks
reasonable - but there are a few things in particular:

+static const char DOS_EXT_ATTR[] = "user.dosattrbuf";

This needs to be in local.h, as a #define.

+#define SMBFATTR_OP_OK 0x00000000
+#define SMBFATTR_OP_NOATTR 0x00000001
+#define SMBFATTR_OP_FAILED 0x00000002

This should be an enum.

Can you clean this up into two parts - an argument for the Samba patch,
and an RFC-style (if not completely formal) document we can pass around
to groups like Wine?   

In particular remember that for other groups involved, the particularly
performance path on your particular filesystem isn't nearly as
important, so the interface needs to be defined and defended on other
grounds too.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20031113/a5f29975/attachment.bin