Neil Brown <neilb@xxxxxxx> wrote: > ctime and mtime have real cache-coherence semantics which require them being > updated by the kernel (whether the cache is on an NFS client, in a backup > archive, or in a .o translation of a .c file). So does creation time, at least for CIFS caching. Creation time has potential for spotting when the object at a pathname has changed for something else, given the lack of inode number and inode generation from windows servers. Creation time gives us one more datum to use. > The only role the kernel might have would be setting the 'creation time' when > the file was created, but it seems even that isn't always what is wanted, > because people don't so much what the time of create of the > container-on-disk, but the time of creation of the data-content. That should be a timestamp in the content itself, not a filesystem metadata timestamp. > I would want to see a pretty convincing use-case that cannot be solved with > xattrs before 'creation time' was added to a generic kernel interface. Then there's no point even considering this. You could emulate the entirety of stat() with getxattr(). I've previously posted a patch to implement the retrieval of creation time, inode gen and data version as xattrs and been told that it's the wrong way to do it and I should extend stat instead. > So just use xattrs and don't involve the kernel in any detailed knowledge of > this value. Why not? BSD has it in its stat struct. Windows has it in its Win32 equivalents. Samba for one will look for it there, and use it if it is. Using an xattr means an extra pathwalk and extra locking per access for any program that wants it. It's a reasonable bet such a program will also be stat'ing the file it wants the creation time for. If we are going to extend stat anyway, then why not make out a short list of extra things we could usefully return and consider adding them? Something like creation time is reasonably easy to come by for little extra overhead. Ext4, for example, retains a copy of it in RAM in its inode struct. > Maybe xstat should take a list of xattrs to be retrieved as well?? or maybe > not. The idea of xstat() having a variable-length buffer and variable arguments has been well derided. It ain't going to happen, much though I'd like it to. I'd quite like to offer the opportunity to return the security label, for example. 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
