[issue12978] Figure out extended attributes on BSDs

[Ned Deily]

Ned Deily  added the comment:

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.

--
versions: +Python 3.8 -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +1783

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[William Orr]

William Orr added the comment:

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.

--
Added file: http://bugs.python.org/file40946/extattrs.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[Ned Deily]

Ned Deily added the comment:

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.

--
stage:  - patch review
versions: +Python 3.6 -Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12978
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[Billy Foster]

Billy Foster added the comment:

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...

--
nosy: +billyfoster

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12978
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[William Orr]

William Orr added the comment:

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.

--
keywords: +patch
nosy: +worr
Added file: http://bugs.python.org/file39095/initial_freebsd_xattrs.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12978
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[Ronald Oussoren]

Changes by Ronald Oussoren ronaldousso...@mac.com:


--
nosy: +ronaldoussoren

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12978
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[Ronald Oussoren]

Ronald Oussoren added the comment:

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12978
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[koobs]

koobs koobs.free...@gmail.com added the comment:

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12978
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[koobs]

koobs koobs.free...@gmail.com added the comment:

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=extattrsektion=2manpath=FreeBSD+9.0-RELEASE

--
nosy: +koobs

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12978
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:


--
nosy: +Arfrever

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12978
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[Hynek Schlawack]

Changes by Hynek Schlawack h...@ox.cx:


--
nosy: +hynek

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12978
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[Benjamin Peterson]

Benjamin Peterson benja...@python.org added the comment:

2012/3/12 Nicholas Riley rep...@bugs.python.org:

 Nicholas Riley com-python-b...@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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12978
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[Nicholas Riley]

Nicholas Riley com-python-b...@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?

--
nosy: +nriley

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12978
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[Nicholas Riley]

Changes by Nicholas Riley com-python-b...@sabi.net:


--
nosy: +bob.ippolito

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12978
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[Benjamin Peterson]

New submission from Benjamin Peterson benja...@python.org:

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);

--
messages: 144028
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: Figure out extended attributes on BSDs
versions: Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12978
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[Ned Deily]

Ned Deily n...@acm.org added the comment:

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

--
nosy: +ned.deily

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12978
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com