[lsb-discuss] statfs specification addition: review
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
> like 'FILESYSTEM_SUPPORTS_CASE_SENSITIVE_LOOKUP'. Instead of looking
> 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.
More information about the lsb-discuss