Re: some gvfs code

[Christian Neumair <chris gnome-de org>]

Am Sonntag, den 08.10.2006, 03:02 +0200 schrieb Alexander Larsson:
> On Fri, 2006-10-06 at 13:32 +0200, Christian Neumair wrote:
> > Am Freitag, den 06.10.2006, 08:48 +0200 schrieb Alexander Larsson:
> > > I spent some time working on out the gvfs API, and I'd like to talk to
> > > people about it on the summit. I've set up a public git repository at
> > > http://www.gnome.org/~alexl/git/gvfs.git so that people can take a look
> > > at it themselves.
> > > 
> > > Note, this is in no way finished, but the core APIs that most apps
> > > (except nautilus and the filemanager) use are mostly there. The "simple"
> > > backend that only accesses local files is somewhat fleshed out (it
> > > lackes some things like mime detection), but please ignore the "unix"
> > > backend and the daemon, since that is mainly a shell with no
> > > implementation yet.
> > 
> > You rock so much Alex! :)
> > 
> > Attached is a patch that allows to disable xattr support at build-time,
> > changes the xattr include to <sys/xattr.h>, and adds deps on the
> > generated marshalling files for the gvfs sources.
> 
> Pushed.
> 
> I changed the include to attr/xattr.h, as that is what man getxattr says
> on my system. Also, my lib is called libattr, not libxattr, so i had to
> change that too. 

Interesting - asking google revealed the following results:

It looks like both glibc (2.3 and above) and libattr provide an xattr
header, see [1] for a thread that discusses whether and how xattr
functionality should be included in glibc, [2] claims that the library
symbols are already included in glibc 2.3 and linking against libattr is
useless because the glibc symbols will be preferred. objdump seems to
confirm this claim, although many KDE applications depend on the
Debian/Ubuntu package libattr1, so either the KDE guys are trying to be
backwards compatible with glibc 2.2. or they didn't realize this shift.

My personal preference would be to simply check for <sys/xattr.h>
presence, and only look for libattr if that fails to support glibc 2.2.
If either libattr is present, or <sys/xattr.h> is around, HAVE_XATTR
would be used. As claimed in a followup of [1], the glibc syscalls are
stubbed out for operating systems not supporting xattrs, and will return
ENOSYS.

[1] http://sources.redhat.com/ml/libc-alpha/2002-08/msg00086.html
[2] http://www.nsa.gov/selinux/list-archive/0310/thread_body85.cfm

-- 
Christian Neumair <chris gnome-de org>