Steve French <smfrench@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
