This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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:06nicholas.rileysetrecipients: + nicholas.riley, benjamin.peterson, ned.deily
2012-03-12 22:51:06nicholas.rileysetmessageid: <1331592666.21.0.069109435319.issue12978@psf.upfronthosting.co.za>
2012-03-12 22:51:05nicholas.rileylinkissue12978 messages
2012-03-12 22:51:05nicholas.rileycreate