[clue-tech] mtime isn't

[marcus hall]

On Thu, Apr 09, 2009 at 09:58:22AM -0600, David L. Willson wrote:
> 
> 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.

Well, I suspect that there wasn't a whole lot of thought given at the time
as to what the proper behavior should be (that is, when the cp command was
originaly written, in the mid 70s), it was likely just written to copy the
file as simply as possible.

>  I can think of good reasons to preserve the mtime and none to destroy it.

Well, "destroy" depends on your point of view.  It could as easily be stated
the other way around that you say that cp should "ignore" the mtime of the
newly created file.

I did give one good reason for updating the mtime on the new file...  If you
are running an incremental backup, you are looking for files that have been
changed since the last backup.  I would expect that this new file should be
backed up, and the mtime tells me that it has changed since the last time
that an incremental backup was run...

Besides, there are many properties of an inode that are "destroyed" when you
make a copy of the file.  Ownership is "destroyed", as you own the new file;
permissions are potentially "destroyed" depending on your umask settings,
etc.

On newer version of cp, there is a "-a" option (for "archive" I think..) that
tries to perserve times, ownership, etc.  Perhaps that is what you want to
use all the time?  I would expect cp to normally make a new copy of the file,
and to me this *should* have an mtime of when the new file was last modified,
not when the original file was modified, so that is what seems intuitively
correct to me.

> 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?

I don't believe that this is possible, because the filesystem doesn't know
that the data being written to file "b" is the same that was written to
file "a".  I think that your complaint belongs with the "cp" command, since
that is the command that knows that a copy is going on.  You could always
alias "cp" to "cp -a", or write a small script that does something similar
(perhaps processing an "anti-a" option as well).

What should happen for the command:

	cat a >b

Should the mtime of b be the same as a, or the current time?

Marcus Hall
marcus at tuells.org