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. With the best regards, Vyacheslav Dubeyko. > -- > 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 -- 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
