Re: preserving mtime

["Martin Langhoff" <martin.langhoff@gmail.com>]

On Nov 19, 2007 7:47 AM, David Brown <git@davidb.org> wrote:
> On Sun, Nov 18, 2007 at 10:34:55PM +1300, Martin Langhoff wrote:
>
> >I do hope anyone doing those things is _very_ aware that the mtime
> >metadata has a specific meaning -- when did this specific file in this
> >filesystem last change -- and is used by many tools in that sense. You
> >are trying to use it for something else. Lots of things will break.
> >
> >Like incremental backups, for example.
>
> 'mtime' does _not_ have the specific meaning of 'when did this specific
> file last change'.  That is the 'ctime' field.  'mtime' is also updated
> when a file is modified, but can be changed by the user.  Many utilities
> restore mtime to older values, including tar.

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.

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.

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

cheers,


m