Re: Modules/attr.c compile error on Mac OS X

["FranÃois Revol" <revol@xxxxxxx>]

> The new Modules/attr.c does not compile on Mac OS X (and probably
> others):
> gcc -c -I.  -DHAVE_CONFIG_H -DMODULE -Wall -Wmissing-prototypes -O2
> -fno-common -o attr..o attr.c
> attr.c: In function 'bin_getattr':
> attr.c:45: error: too few arguments to function 'listxattr'
> attr.c:46: error: too few arguments to function 'getxattr'
> attr.c: In function 'bin_setattr':
> attr.c:70: error: too few arguments to function 'setxattr'
> attr.c: In function 'bin_delattr':
> attr.c:84: error: too few arguments to function 'removexattr'
> attr.c: In function 'bin_listattr':
> attr.c:99: error: too few arguments to function 'listxattr'

Likely the xattr API OSX supports isn't compatible with the withdrawn-
POSIX-draft implemented in Linux...

Generally speaking xattrs are very different from one OS to another,
and aren't compatible on all API, storage and semantics level.

For example, BeOS has made pervasive use of xattrs for over a decade,
though its are typed (uint32 4CC code) and indexable on BFS, and the
API also allows for a 64bit offset inside it, though it wasn't
implemented in BFS, cf.
http://www.beos.tarman.pl/teksty/bebookpl/The%20Storage%20Kit/AttrFuncs.html

Even on Linux I recall finding 3 different API, some taking void * for
the value field, others using char *...

cf. Linux manpage:
http://linux.die.net/man/2/getxattr

     ssize_t getxattr (const char *path, const char *name,
     void *value, size_t size);
(though the kernel API is different, and there are/were other APIs)

cf. BSD manpage:
http://www.manpagez.com/man/2/getxattr/
     ssize_t
     getxattr(const char *path, const char *name, void *value, size_t
size,
         u_int32_t position, int options);

The OSX ones likely use the BSD API, and should map quite well 1:1 at
the API level to the Linux ones, but I'm not sure about the storage
level though, on Linux the user-accessible namespace is restricted to
"user.*".
Not even mentionning the different semantics of walking interaction
(NOFOLLOW...), or value interpretation (void * vs char * that can be
binary vs char * that means string, vs typed binary value..., or even a
full directory tree as it's possible on Solaris)

Ideally a mangling scheme onto a common name/value space would be
designed to allow mapping every OS xattrs in such a way that the scheme
is idempotent (can be reused on itself multiple times through different
protocols (NFS,extended FTP,...), OS and file system (NTFS, ext2,
BFS...) and still keeping the initial information usable to the
originator).

But that will need a cross-OS coordination, and a lot of work to make
people agree. Been thinking about this for quite some time...

As for zsh, at least it should probably have a separate backend for
each platform for clarity, until such a mangling scheme is devised.

FranÃois.