Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Mar 2008 21:49:22 +0100
From:      =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= <v.haisman@sh.cvut.cz>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: Indication of extended attributes availability.
Message-ID:  <47E570D2.8010502@sh.cvut.cz>
In-Reply-To: <20080322195758.K32322@fledge.watson.org>
References:  <47E43496.5080201@sh.cvut.cz> <20080322180253.B27442@fledge.watson.org> <47E55BC1.9080707@sh.cvut.cz> <20080322195758.K32322@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig54B26AFB8CBA7B89DA286B4A
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Robert Watson wrote, On 22.3.2008 21:00:
 >[...]
> mount flags are normally used for places where there is a desire to=20
> report an administrative setting, and on the whole, extended attributes=
=20
> are a property of the file system type, and not a per-mount setting. =20
> UFS1 extended attributes are intended to be the exception rather than=20
> the rule.  The way fpathconf() works inside the kernel is that the=20
> request is delivered directly to the file system that implements the=20
> target of the path provided, so it can return information on whatever=20
> granularity it wants -- be it per-mount, per-volume, etc.  I think the =

> Solaris model sounds pretty sensible, although one thing worth=20
> considering is that Solari's extended attributes may, in fact, be file =

> forks or streams, and called extended attributes due to NFSv4 using tha=
t=20
> terminology (an unfortunate overloading inconsistent with the use in=20
> many OS's).  In which case we might want to use a different name.  It=20
> would be worth checking Linux and Mac OS X as well.
>=20
I have done some digging using the Man pages mirrors on www.freebsd.org.

1. Only Solaris has the _PC_XATTR_*. According to=20
<http://www.freebsd.org/cgi/man.cgi?query=3Dfsattr&apropos=3D0&sektion=3D=
0&manpath=3DSunOS+5.10&format=3Dhtml>=20
  _PC_XATTR_* are really about extended attributes. Citation from the pag=
e:

"Not all implementations are able to, or want to, support the full model.=
 For=20
example, the implementation for the UFS file system allows only regular f=
iles=20
as attributes (for example, no sub-directories) and rejects attempts to p=
lace=20
attributes on attributes."

This sounds close enough to what FreeBSD has.

2. Neither Linux nor Darwin seem to support querying availability of exte=
nded=20
attributes even though they support their use using getxattr() etc.


--
VH


--------------enig54B26AFB8CBA7B89DA286B4A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH5XDaoUFWwtEPkHIRCHjdAKCApzngtIyer0wOpwnnn2dbW7f08gCeO9Nf
FWDhAt3gbuoEVsuHs8VUa+0=
=CZeq
-----END PGP SIGNATURE-----

--------------enig54B26AFB8CBA7B89DA286B4A--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47E570D2.8010502>