Message155505
| Author |
nicholas.riley |
| Recipients |
benjamin.peterson, ned.deily, nicholas.riley |
| Date |
2012年03月12日.22:51:05 |
| SpamBayes Score |
2.883634e-07 |
| Marked as misclassified |
No |
| Message-id |
<1331592666.21.0.069109435319.issue12978@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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? |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年03月12日 22:51:06 | nicholas.riley | set | recipients:
+ nicholas.riley, benjamin.peterson, ned.deily |
| 2012年03月12日 22:51:06 | nicholas.riley | set | messageid: <1331592666.21.0.069109435319.issue12978@psf.upfronthosting.co.za> |
| 2012年03月12日 22:51:05 | nicholas.riley | link | issue12978 messages |
| 2012年03月12日 22:51:05 | nicholas.riley | create |
|