Indication of extended attributes availability.

Robert Watson rwatson at FreeBSD.org
Sat Mar 22 20:00:32 UTC 2008


On Sat, 22 Mar 2008, Václav Haisman wrote:

>> I think the preferred programmatic approach is actually via fpathconf(2). I 
>> don't know if any other OS's have assigned a _PC constant for extended 
>> attributes, but if they have we should probably use the same one. 
>> However, I guess there's a meta-question: is your goal to allow programs to 
>> be able to tell if extended attributes are available, or for administrators 
>> to be able to tell?
>
> My original intent was to just extend /bin/cp with switch that would allow 
> copying of extended attributes together with the contents of files. When I 
> looked at its source I noticed that it uses fpathconf() for querying for 
> ACLs capability. Because I have not found extended attributes in 
> fpathconf(2) I have looked at statfs(2) but there is nothing there either. 
> So I thought the information would have to be conveyed to either of the 
> syscalls somehow. The mnt_flag field of struct mount seems like a logical 
> place to put the information into. From there it seems it could be used by 
> either fpathconf() or statfs() or both.
>
> So, to answer the question, the goal is to allow programs to detect extended 
> attributes availability.
>
> As to what other OSes do, Solaris mentions _PC_XATTR_ENABLED and 
> _PC_XATTR_EXISTS in fpathconf(2).

mount flags are normally used for places where there is a desire to report an 
administrative setting, and on the whole, extended attributes are a property 
of the file system type, and not a per-mount setting.  UFS1 extended 
attributes are intended to be the exception rather than the rule.  The way 
fpathconf() works inside the kernel is that the request is delivered directly 
to the file system that implements the target of the path provided, so it can 
return information on whatever granularity it wants -- be it per-mount, 
per-volume, etc.  I think the Solaris model sounds pretty sensible, although 
one thing worth considering is that Solari's extended attributes may, in fact, 
be file forks or streams, and called extended attributes due to NFSv4 using 
that terminology (an unfortunate overloading inconsistent with the use in many 
OS's).  In which case we might want to use a different name.  It would be 
worth checking Linux and Mac OS X as well.

Robert N M Watson
Computer Laboratory
University of Cambridge


More information about the freebsd-fs mailing list