On Wed, Jul 05, 2006 at 05:12:54PM -0400, Bill Davidsen wrote:But with timestamps I need remember only one number, the time of my last backup. Skipping over the question of "who's idea of time" inherent in network filesystems. I compare all ctimes with the time of the last backup and do incremental on the newer ones. If we use versioning I have to remember the version for each file! In practice I really question if the benefit justified keeping all that metadata between backups. And if I delete a file and create another by the same name, what is it's version?
J. Bruce Fields wrote:
Or we could add an entirely separate attribute that's guaranteed toThere are versions in both VMS and the ISO filesystem. I have a sneaking suspicion that those of us who ever use them are few and far between. The other issue is that unless the field is time, programs like make can't really use it, at least without becoming Linux specific.
increase whenever the ctime is updated, and that doesn't necessarily
have any connection with time--call it a version number or something.
Sure.
I'm not sure exactly how a "version" value would be used other than detecting the fact that the file had been changed in some way.
I agree. But "detecting the fact that the file has been changed" is a
really important use! I think the challenge would be to come up with
applications that really depend on timestamps and that use them for
anything *other* than detecting when a file has changed.
(OK, so make is a special case--it cares not only about whether a file
has changed, but also about whether it has changed more recently than
some other file. But I'd think a simple version would useful to any
network filesystem, or more generally to anything that caches a view of
the filesystem either on another machine or in userspace.)
Feel free to show me, I seem to come up empty on using this value.
Betraying my own interests--the NFSv4 protocol (unlike v2 or v3) uses a
specialized "change" attribute to maintain cache consistency instead of
depending on mtime/ctime. So nfsd would be one immediate in-kernel
user. Currently we're using ctime, which causes obvious problems.
But an improved ctime--one that actually increased whenever the file
changed--would also do the job.