Author benjamin.peterson
Recipients benjamin.peterson, bob.ippolito, ned.deily, nicholas.riley
Date 2012-03-14.15:14:16
SpamBayes Score 2.71627e-09
Marked as misclassified No
Message-id <>
In-reply-to <>
2012/3/12 Nicholas Riley <>:
> Nicholas Riley <> added the comment:
> I've spent a few hours looking at xattr and the Linux/OS X (10.4+) implementations.  Bob Ippolito's xattr module implements the OS X xattr interface on Linux, Solaris (9+) and FreeBSD.  Linux and OS X are pretty close; FreeBSD and Solaris are substantially different from either and the Solaris implementation is somewhat incomplete/broken.
> The OS X differences from Linux are:
> • Instead of l* functions, the XATTR_NOFOLLOW option
> • XATTR_NOSECURITY and XATTR_NODEFAULT are in the headers but essentially unavailable as the kernel code always returns EINVAL for them.
> • XATTR_SHOWCOMPRESSION to expose the HFS compression stuff, which I can't imagine many people needing
> • XATTR_MAXNAMELEN (but no equivalent to XATTR_SIZE_MAX).  Linux has a corresponding XATTR_NAME_MAX, which we should probably expose too.
> • XATTR_FINDERINFO_NAME and XATTR_RESOURCEFORK_NAME for some standard attribute names.  I would imagine these are worth exposing.
> I don't see any problems supporting the currently exposed Linux API on OS X  (I could probably find a usable value for XATTR_SIZE_MAX), but it's unclear if that is the right way to go forward.
> Suggestions?

Thanks for looking into this. I think the best approach at the moment
is try to wrap these differences under the LInux API. It seems the
biggest one will just be adding XATTR_NOFOLLOW for the l* calls.
Date User Action Args
2012-03-14 15:14:18benjamin.petersonsetrecipients: + benjamin.peterson, nicholas.riley, bob.ippolito, ned.deily
2012-03-14 15:14:17benjamin.petersonlinkissue12978 messages
2012-03-14 15:14:16benjamin.petersoncreate