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>