Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!cit-vax!mangler
From: mangler@cit-vax.Caltech.Edu (System Mangler)
Newsgroups: comp.unix.questions
Subject: Re: file times
Message-ID: <2478@cit-vax.Caltech.Edu>
Date: Sun, 26-Apr-87 03:40:36 EDT
Article-I.D.: cit-vax.2478
Posted: Sun Apr 26 03:40:36 1987
Date-Received: Sun, 26-Apr-87 23:07:32 EDT
References: <12854@watnot.UUCP> <6362@mimsy.UUCP> <12905@watmath.UUCP> <861@xanth.UUCP>
Distribution: na
Organization: California Institute of Technology
Lines: 18
Summary: why do link(), unlink() change ctime?

In article <861@xanth.UUCP>, john@xanth.UUCP (John Owens) writes:
> [...] mv'ing the file changes the ctime, [...]

Does anything other than /etc/dump look at the ctime?
(Don't mention rogue's check for saved-game fraud).

If not, then there is no need for link(), unlink(), and rename()
to change the ctime, since any such operation necessarily updates
a directory, which should be enough information for /etc/restore,
without needing to clutter the dump tape with the unchanged contents
of the renamed file.

Historically, restor [sic] wanted to have the inode on the tape to
make sure the link count got updated.  Even if the link count didn't
get adjusted, fsck routinely fixes those.  With restor (almost) gone,
perhaps this behaviour is no longer useful.

Don Speck   speck@vlsi.caltech.edu  {seismo,rutgers,ames}!cit-vax!speck