From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11232 invoked from network); 8 Mar 2009 09:08:49 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00,INVALID_DATE autolearn=no version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 8 Mar 2009 09:08:49 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 46089 invoked from network); 8 Mar 2009 09:08:44 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 8 Mar 2009 09:08:44 -0000 Received: (qmail 25733 invoked by alias); 8 Mar 2009 09:08:39 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26696 Received: (qmail 25716 invoked from network); 8 Mar 2009 09:08:39 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 8 Mar 2009 09:08:39 -0000 Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by bifrost.dotsrc.org (Postfix) with ESMTP id BAFBA80307F8 for ; Sun, 8 Mar 2009 10:08:35 +0100 (CET) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id B0DA4D480F9; Sun, 8 Mar 2009 10:08:32 +0100 (CET) Received: from laptop (vaf26-2-82-244-111-82.fbx.proxad.net [82.244.111.82]) by smtp5-g21.free.fr (Postfix) with ESMTP id BAD48D480F7; Sun, 8 Mar 2009 10:08:29 +0100 (CET) In-Reply-To: <16c5bb260903080021k4da0e6b1g8e40cc7520f84e8@mail.gmail.com> To: Taro M Subject: Re: Modules/attr.c compile error on Mac OS X Cc: zsh-workers@sunsite.dk X-Mailer: BeMail - Mail Daemon Replacement 3.0.0 Final From: "=?utf-8?q?Fran=C3=A7ois?= Revol" Date: Sun, 08 Mar 2009 10:10:33 +0100 CET Message-Id: <1609524143-BeMail@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV 0.92.1/9080/Fri Mar 6 20:13:38 2009 on bifrost X-Virus-Status: Clean > The new Modules/attr.c does not compile on Mac OS X (and probably > others): > gcc -c -I. -DHAVE=5FCONFIG=5FH -DMODULE -Wall -Wmissing-prototypes -O2 > -fno-common -o attr..o attr.c > attr.c: In function 'bin=5Fgetattr': > 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=5Fsetattr': > attr.c:70: error: too few arguments to function 'setxattr' > attr.c: In function 'bin=5Fdelattr': > attr.c:84: error: too few arguments to function 'removexattr' > attr.c: In function 'bin=5Flistattr': > 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=5Ft getxattr (const char *path, const char *name, void *value, size=5Ft size); (though the kernel API is different, and there are/were other APIs) cf. BSD manpage: http://www.manpagez.com/man/2/getxattr/ ssize=5Ft getxattr(const char *path, const char *name, void *value, size=5Ft size, u=5Fint32=5Ft 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=C3=A7ois.