On Thu, 2013-12-26 at 01:48 -0800, Christoph Hellwig wrote:
> On Tue, Dec 24, 2013 at 10:41:44AM +0400, Vyacheslav Dubeyko wrote:
> > > -
> > > - if (strncmp(name, XATTR_MAC_OSX_PREFIX,
> > > - XATTR_MAC_OSX_PREFIX_LEN) == 0)
> > > - name += XATTR_MAC_OSX_PREFIX_LEN;
> >
> > Removing this skipping of virtual "osx." prefix means that you save it
> > on volume. But such action means volume corruption really. Because HFS+
> > volume hasn't such prefixes for xattrs in AttributesFile. Usually,
> > special xattrs has prefix "com.apple.*" but others haven't any prefix
> > and can be named as you want. So, I think that it is not correct
> > modification.
>
> With my patch applied we don't add the prefix that later gets stripped
> in the first place:
>
> - hfsplus_osx_setxattr gets called without the prefix from the VFS code
> - the code to add the prefix in hfsplus_osx_setxattr is removed by the
> patch
> - the code to remove it again in __hfsplus_setxattr is removed as well
>
> Because of the way the handlers work no other caller of
> __hfsplus_setxattr should ever have a name with the osx prefix.
>
> Same for the getxattr side.
I feel some confusion. :) As far as I can see, generic handlers are
connected with a prefix:
const struct xattr_handler hfsplus_xattr_osx_handler = {
.prefix = XATTR_MAC_OSX_PREFIX,
.list = hfsplus_osx_listxattr,
.get = hfsplus_osx_getxattr,
.set = hfsplus_osx_setxattr,
};
So, if we don't add the "osx." prefix on the fly then it means that we
don't call proper handler. HFS+ doesn't keep "osx." prefix on the volume
because this prefix is Linux way only to process xattrs. For example, I
can create xattr with name "test" under Mac OS X. And this xattr's name
hasn't "osx." prefix. Can I access to this xattr under Linux if we don't
add "osx." prefix on the fly?
Maybe I misunderstand some part of your patch set?
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
