--- On Wed, 26/9/12, Vyacheslav Dubeyko <slava@xxxxxxxxxxx> wrote: > Hi, > > On Wed, 2012-09-26 at 08:13 -0400, Christoph Hellwig wrote: > > On Tue, Sep 25, 2012 at 02:57:04PM +0400, Vyacheslav > Dubeyko wrote: > > > As I can understand, you are talking about using > xattr_handler's for > > > dispatching of processing of extended attributes > with such complex names > > > as "system.posix_acl_access" and so on. Am I > correct? > > > > > > The HFS+ has such peculiarities that you can name > extended attribute as > > > you want. And name of extended attribute can keep > in Attributes Tree > > > without any prefixes (for example, as "test"). > Moreover, it is not used > > > such prefixes as "user." or "system." under Mac OS > X. > > > > But we will have to use them under Linux. The > whole xattr mechanism > > is built around the model that we decide policies, > including most > > importantly access control, based on these > prefixes. In retrospective > > I think the string prefixes are a horrible idea and a > simple binary > > flag namespace as done by e.g. IRIX or FreeBSD would > have made everyones > > life a heck lot simpler, but that's not what we > implemented 10 years > > ago. > > > > > However, it exists under Mac OS X special prefix > "com.apple." (for > > > example, "com.apple.FinderInfo"). So, you suggest > to add definition of > > > additional prefixes "com." and "apple." in > include/linux/xattr.h and to > > > add xattr_handler's for these two prefixes. Am I > correct? > > > > No. I'd suggest mapping any free-form attributes > in hfsplus into user.* > > in the syscall namespace, while only mapping a few that > needs special > > treatment into system.* or similar. Using the > proper helpers will make > > this actually readable at least. > > > > So, it means that it needs to add special prefix "user." > during > listxattr phase for any free-form attributes. And then it > needs to > expect on the getxattr phase names with artificially added > prefixes (for > example, user.<real-name>) and ignores requests with > only real name of > attribute (real name means name of extended attribute that > keeps in > metadata). > > But it can really confuse, from my point of view. Let's > imagine that you > firstly, mount your HFS+ volume under Mac OS X and, > secondly, under > Linux. Under Mac OS X you can see real names of the extended > attributes > but under Linux you will see another artificially > constructed names of > extended attributes for the same file system object: > > Mac OS X -> "test" > Linux -> "user.test" > > I think this situation can be a very confusing and > unexpected for the > end-user. For example, if I remember extended attribute name > that I got > under Mac OS X then I can try to get it content by name > under Linux (but > will fail in such situation). > > I totally agree that it needs to implement prefixes support > for the ACLs > case. But I think that it is not proper way for free-form > extended > attributes. It needs to remember about possible using the > same HFS+ > volume as under Mac OS X as under Linux. I am with Vyacheslav on this - while we should implementing user.* system.* for ACLs , we should not perverse meanings/familiarities of current-, and possibly future-, use of extended attributes in HFS+ under Mac OS X. In a related but opposite scenario, currently, com.apple.* have special meanings under Mac OS X. If we do map that to system.* , there would be the possibility of a user creating a system.* attribute under linux, which becomes a com.apple.* under Mac OS X, and breaking its use in Mac OS X in small or big ways. Whereas if a user does mess with com.apple.*, he could reasonably expect problems when he tries to use the media under Mac OS X. There are some patches and reports relating to backing up and restoring Mac OS X with tar or rsync and breaking things on the way. I think we can create/delete/use xattrs in any way, but we should not represent the attribute's names differently to the user. Regards, Hin-Tak -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
