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.

classification
Title: Figure out extended attributes on BSDs
Type: Stage: patch review
Components: Versions: Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, benjamin.peterson, billyfoster, bob.ippolito, hynek, koobs, ned.deily, nicholas.riley, ronaldoussoren, worr
Priority: normal Keywords: patch

Created on 2011-09-14 15:35 by benjamin.peterson, last changed 2022-04-11 14:57 by admin.

Files
File name Uploaded Description Edit
initial_freebsd_xattrs.patch worr, 2015-04-18 02:52 review
extattrs.patch worr, 2015-11-05 07:21 review
Pull Requests
URL Status Linked Edit
PR 1690 open python-dev, 2017-05-21 04:04
Messages (12)
msg144028 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2011-09-14 15:35
Extended attribute support currently exists in the os module for Linux. BSD's (including OSX) have a similar (but of course incompatible) interface. They should be exposed through the same functions. For example,

os.getxattr("myfile", "user.whatever")

should call on the C level

getxattr("myfile", "user.whatever", value, sizeof(value), 0, 0);
msg144035 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2011-09-14 18:36
Have you looked at Bob Ippolito's xattr module which has been out for some time and wraps Linux, OS X, BSD, and Solaris extended attributes?

http://pypi.python.org/pypi/xattr
msg155505 - (view) Author: Nicholas Riley (nicholas.riley) * Date: 2012-03-12 22:51
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?
msg155756 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2012-03-14 15:14
2012/3/12 Nicholas Riley <report@bugs.python.org>:
>
> Nicholas Riley <com-python-bugs@sabi.net> 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.
msg165551 - (view) Author: Kubilay Kocak (koobs) (Python triager) Date: 2012-07-15 21:46
FreeBSD (at least on 7.x, 8.x and 9.x) has the following syscalls available in its API:

extattr_{get,set,list,delete}_{fd,file,link}

And also has: EXTATTR_MAXNAMELEN

http://www.freebsd.org/cgi/man.cgi?query=extattr&sektion=2&manpath=FreeBSD+9.0-RELEASE
msg165578 - (view) Author: Kubilay Kocak (koobs) (Python triager) Date: 2012-07-16 08:20
And to clarify the no-follow-symlinks case on FreeBSD:

extattr_{get,set,list,delete}_link "system calls behave in the same way as their _file counterparts, except that they do not follow sym-links." as per the man page.
msg193732 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2013-07-26 15:23
The OSX API also has a "position" argument for both getting and setting extended attributes. The position should be 0 for normal attributes, and can have other values when accessing the resource fork of a file.
msg241392 - (view) Author: William Orr (worr) * Date: 2015-04-18 02:52
Here's an initial attempt at implementing extended attribute support. Let me know if there's any interest.

There's currently one deficiency, which is that the namespace isn't prepended to the attribute name when calling lsxattr.

Let me know if my approach is good, so I can continue fixing lsxattr. All other unit tests pass.
msg247000 - (view) Author: Billy Foster (billyfoster) Date: 2015-07-20 18:56
Is there any chance of getting this finalized?  I have been using William Orr's patch as a workaround for months now, but it would be nice to not have to manually apply it each version bump...
msg247308 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2015-07-25 01:56
There certainly is interest in supporting extended attributes on additional platforms.  Thanks for the patch, William, and the positive comments, Billy.  Since this probably falls into the category of new feature, it should be targeted for 3.6, now that 3.5 is in feature-freeze and nearing release.  The gating factor is getting a core developer to review and champion it.
msg254089 - (view) Author: William Orr (worr) * Date: 2015-11-05 07:21
After a considerable amount of rework, I've gotten something worth submitting. All unit tests pass, and it handles some of the more unfortunate differences between FreeBSD's extended attribute syscalls and Linux's.

One of the bigger changes is that I reworked the calls to getxattr and listxattr. These used to be called with a small buffer, and if the size of the extended attribute(s) exceeded the buffer length, we'd throw out that buffer and start again with a buffer of the maximum possible attribute size allocated.

I threw this out, and opted for always making two calls - one to get the size of the buffer, and one to actually get the contents (or list of attributes). This works the same for both FreeBSD and Linux. FreeBSD's extattr_get_* and extattr_list_* unfortunately only return the number of bytes read, *not* the number of bytes in the attribute value or the list. That means that there's no real way to determine if we've read less data than there is in the attribute.

This passes the unit tests (on FreeBSD 10.1). I'd be interested to see results from other users and comments.
msg327502 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-10-10 23:45
On 2018-10-02, worr asked on the python-dev mailing list:
> Can I get a review for GH-1690[PR 1690]? It fixes bpo-12978 and
> has been sitting for a handful of years now. This adds
> support for os.*xattr on DragonflyBSD, FreeBSD and NetBSD.
History
Date User Action Args
2022-04-11 14:57:21adminsetgithub: 57187
2018-10-10 23:45:24ned.deilysetmessages: + msg327502
versions: + Python 3.8, - Python 3.6
2017-05-21 04:04:31python-devsetpull_requests: + pull_request1783
2015-11-05 07:22:01worrsetfiles: + extattrs.patch

messages: + msg254089
2015-07-25 01:56:13ned.deilysetstage: patch review
messages: + msg247308
versions: + Python 3.6, - Python 3.3
2015-07-20 18:56:55billyfostersetnosy: + billyfoster
messages: + msg247000
2015-04-18 02:52:53worrsetfiles: + initial_freebsd_xattrs.patch

nosy: + worr
messages: + msg241392

keywords: + patch
2013-07-26 15:23:35ronaldoussorensetmessages: + msg193732
2013-07-26 14:33:16ronaldoussorensetnosy: + ronaldoussoren
2012-07-16 08:20:33koobssetmessages: + msg165578
2012-07-15 21:46:26koobssetnosy: + koobs
messages: + msg165551
2012-07-15 03:00:04Arfreversetnosy: + Arfrever
2012-04-10 18:29:30hyneksetnosy: + hynek
2012-03-14 15:14:17benjamin.petersonsetmessages: + msg155756
2012-03-12 22:52:04nicholas.rileysetnosy: + bob.ippolito
2012-03-12 22:51:05nicholas.rileysetnosy: + nicholas.riley
messages: + msg155505
2011-09-14 18:36:31ned.deilysetnosy: + ned.deily
messages: + msg144035
2011-09-14 15:35:25benjamin.petersoncreate