Re: preserving mtime

From: David Brown <git@davidb.org>
Date: Nov 18, 2007, 21:44 UTC
Message-ID: <20071118214403.GA7182@old.davidb.org>
In-Reply-To: <46a038f90711181236o1acd00d4id9c5aeffd3065b80@mail.gmail.com>

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

Show 5 quoted lines

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

Show 9 quoted lines

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

Show 7 quoted lines

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