Re: [PATCH 0/3] Extended file stat functions

[David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> How does a fs return an "unknown" value for one
> (e.g. version field) ... 0  or -1  or ...

Well, for the new creation time, inode version and data version fields, the
query_flags field has a bit for each that's set if the field contains a value,
and is clear if it doesn't.

See the test program on patch 3.

> One hole that this reminded me about is how to return the superblock
> time granularity (for NFSv4 this is attribute 51 "time_delta" which
> is called on a superblock not on a file).  We run into time rounding
> issues with Samba too.

That sounds like something that should be accessible through statfs.  But it
could be made accessible here too.  It would also apply to FAT, which I
believe has a 2s granularity.

> >  (4) Should the inode number and data version number fields be 128-bit?
> This is tricky for SMB2, if you can also provide a device id (or an object
> id of some sort for the superblock) then 64 bit inode number is ok.

A remote device ID?  That would be possible.  That could be used by AFS to
return the numeric volume ID (32 bits) and by NFS to return the FSID (128
bits).  Would you be using the VolumeGUID (128 bits) for SMB2?


David