[clue-tech] mtime isn't

[David L. Willson]

... from the filesystem's view, things have
> changed.
> For instance, if you ran something like "find . -mtime -7" looking for
> the
> files that need to be backed up because they have changed in the last
> week, should it make a backup of t.cp?

Marcus, all,

I might argue that this behavior is non-intuitive without justification.  Now, I understand why it behaves this way from a technical standpoint, but I still don't understand why this behavior was selected to be the default.  I can think of good reasons to preserve the mtime and none to destroy it.  I believe that default behaviors should either match "what folks expect", or have a darn good reason for not doing so.  Technical necessity is a good reason, so is some practical reason that might not be obvious to the users.  It seems to me that the one-line backup described above doesn't justify updating (destroying) mtime, because it could work intuitively by simply selecting files on ctime, rather than mtime.  'ctime' ceems like a better match for the desired selection anyway.

Is there a Linux filesystem that tracks timestamps for file creation, file open for read, metadata or security change, and content change a more natural way, or is this a function of the filesystem interface, not the filesystem itself?