[lsb-discuss] statfs specification addition: review

Theodore Tso tytso at mit.edu
Thu Dec 21 10:46:29 PST 2006

On Thu, Dec 21, 2006 at 09:06:13AM -0800, Camp, TracyX E wrote:
> To bring up an alternate suggestion...  It may be _entirely more_
> controversial to introduce an entirely new interface, but the problem
> that applications are trying to solve here is to determine file system
> semantics, not the actual file system name, so why not push for an
> interface that actually solves the real problem?  The file system magic
> or name string should really just be advisory information.
> The NT file system interface exposes a bitmask of attribute flags that
> define various optional semantics (optional in the context of the NT
> operating system that is... Linux has fewer optional semantics).  Things
> for file systems by name (which sadly many applications do anyways) it
> it possible to look for file systems by the feature that you are
> actually interested in. In the case of Linux this is almost always
> locking and cache coherency semantics (i.e. is it NFS?).  

Agreed, this is definitely a much better way to proceed in terms of
long-term portability is concerned.  And, there is actually a standard
interface defined in Posix for this pathconf/fpathconf().  The
question is what semantics do application vendors want to test for?

> But Linux also optionally supports a number of other optional file
> system semantics like xattrs etc, that an application my be
> interested in.  This would solve the relatively 'short' life span of
> file systems in Linux.  So instead of searching for XFS's magic only
> to have the app break when 'TVFS3' comes along and supports xattrs,
> it could be file system agnostic in a safe manner.

Sure, assuming that we've also added the xattr interfaces into the LSB.

						- Ted

More information about the lsb-discuss mailing list