Re: preserving mtime

[David Brown <git@davidb.org>]

On Mon, Nov 19, 2007 at 09:36:52AM +1300, Martin Langhoff wrote:

>Hmmm. After a bit of googling I've found conflicting descriptions of
>the mtime/ctime semantics (I thought - for 10 years now - that ctime
>was "creation time", it is "changed time"). Some people think that
>anything that updates mtime also updates ctime, and others say the
>opposite.

One of them is wrong.  All modifications to the file change the ctime.
Some modifications change the mtime.  There is also a call to change the
mtime (which will touch the ctime).  It's been this way for a long time.
I think most of the confusion comes from the 'c' in ctime.

It doesn't help that the Posix spec is so hard to read on this.  Basically,
you have to look up every command that might modify a file to figure out
which time changes it is supposed to modify.

>Wikipedia says (at http://en.wikipedia.org/wiki/MAC_times and
>http://en.wikipedia.org/wiki/Stat_%28Unix%29 ) that mtime is about the
>content, and ctime about metadata (owner, permissions, moved inode,
>etc). Changes in content "touch" mtime + ctime.
>
>With that in mind, I think it makes sense for things like make and
>amanda to read mtime as referring to a real change of that concrete
>file. The abstract notion of the file having changed in the big DSCM
>in the sky is useful, but putting that data in mtime messes things up.

Backup software should _never_ look at the mtime (other than to save it).
Both GNU tar and dump use the ctime field exclusively for incremental
purposes.

Think about this:

   wget .../linux-2.4.tar.gz
   tar -xzf linux-2.4.tar.gz

I've just expanded lots of files on my machine.  Tar is going to set the
mtime to the date they were at when the tarball was made, which was
probably several years ago.  It is crucial, though, that any backup
software I run still back these files up, since they are newly added.

There are backup programs that use mtime, but they are just broken, plain
and simple.

>> However, it will make 'make' very confusing, since it uses the mtime to
>> determine if files are out of date.  If moving to an older version of a
>> file causes the file to become older, make won't recompile.  This is
>> arguably a defect in make, but that is how it works.
>
>It's not a bug in make. mtime has a definite meaning, and make is
>using that meaning. Same with amanda.

It is very much a bug (well, a feature) in make.  But the whole date
comparison model of make is completely wrong.  It should rebuild a file if
it has changed, not if it is newer.  Most make replacements do something
more intelligent (often similar to the index cache git uses).

I haven't used Amanda for a while, but it at least used to do the right
thing (using ctime).  They might have had to break things to support FAT,
but I would guess it still works on a real filesystem.

David