Re: extended attributes and lsextattr/extattr_list_file

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

Thor Lancelot Simon <tls%panix.com@localhost> wrote:

> > The question remain: how do we produce the Linux/MacOS X/FUSE flavor
> > with NUL terminated strings? It seems the best way is to add a flavor
> > argument to VOP_LISTEXTATTR and let the filesystem do the job. 
> 
> What happens when that (broken) interface runs into a bytestring with
> NULs in it?

Then you are screwed. Extended attrribute semantics differ here but this
is not the only case Here is a summary of the two interfaces differences
I noticed:

listxattr() flistxattr() and llistxattr() 
- #include <sys/xattr.h>
- Attribute names must include a namespace prefix delimited by a dot
(e.g.: system.foo)
- system, trusted, security and user namespaces are predefined with
their own access semantics
- One can use other random namespace, which will behave as user
namespace.
- Attributes names list is returned as NUL-separated strings
- Attribute values cannot contain a NUL character
- Used in Linux, MacOS X and FUSE

extattr_list_file() extattr_list_fd() extattr_list_link() 
- #include <sys/extattr.h>
- Attribute namespace is provided as an int
- system and user namespaces are defined
- Other namespaces values usage is a mystery.
- Attributes names list is returned as one-byte length prefixed, non NUL
terminated strings
- Attribute value cannot cannot be bigger than 255 bytes
- Used in FreeBSD

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost