homepage

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

AltStyle によって変換されたページ (->オリジナル) /