Date: Sat, 22 Mar 2008 20:19:29 +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: <47E55BC1.9080707@sh.cvut.cz> In-Reply-To: <20080322180253.B27442@fledge.watson.org> References: <47E43496.5080201@sh.cvut.cz> <20080322180253.B27442@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) --------------enig94CD03F1E67C4A600BF661CD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Robert Watson wrote, On 22.3.2008 19:05: >=20 > On Fri, 21 Mar 2008, V=C3=A1clav Haisman wrote: >=20 >> I would like to have some sort of indication of extended attributes=20 >> availability for given FS. It seems that things like this (MAC, ACLs=20 >> etc.) are indicated using mount flags and those are available through = >> statfs() call. The following is tentative patch that would expose=20 >> extended attributes availability as mount flag. It is completely=20 >> untested. I would just like to know if it is a viable approach to the = >> problem or should I scratch it and try something else? >=20 > I think the preferred programmatic approach is actually via=20 > fpathconf(2). I don't know if any other OS's have assigned a _PC=20 > constant for extended attributes, but if they have we should probably=20 > use the same one. However, I guess there's a meta-question: is your=20 > goal to allow programs to be able to tell if extended attributes are=20 > available, or for administrators to be able to tell? >=20 My original intent was to just extend /bin/cp with switch that would allo= w=20 copying of extended attributes together with the contents of files. When = I=20 looked at its source I noticed that it uses fpathconf() for querying for = ACLs=20 capability. Because I have not found extended attributes in fpathconf(2) = I=20 have looked at statfs(2) but there is nothing there either. So I thought = the=20 information would have to be conveyed to either of the syscalls somehow. = The=20 mnt_flag field of struct mount seems like a logical place to put the=20 information into. From there it seems it could be used by either fpathcon= f()=20 or statfs() or both. So, to answer the question, the goal is to allow programs to detect exten= ded=20 attributes availability. As to what other OSes do, Solaris mentions _PC_XATTR_ENABLED and=20 _PC_XATTR_EXISTS in fpathconf(2). -- VH --------------enig94CD03F1E67C4A600BF661CD 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 iD8DBQFH5VvIoUFWwtEPkHIRCACQAJ9fbZi+VN0qAEAhTKcNqiEFcaP/MACfdNXf wBW21UqyQWN0aPGr5yhEfPU= =75tu -----END PGP SIGNATURE----- --------------enig94CD03F1E67C4A600BF661CD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47E55BC1.9080707>