Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!think!mit-eddie!genrad!decvax!tektronix!tekgen!tektools!richl
From: richl@tektools.UUCP (Rick Lindsley)
Newsgroups: net.unix-wizards,net.bugs.4bsd
Subject: Re: 4.2BSD restore(8)
Message-ID: <1011@tektools.UUCP>
Date: Mon, 5-May-86 12:39:00 EDT
Article-I.D.: tektools.1011
Posted: Mon May  5 12:39:00 1986
Date-Received: Sat, 10-May-86 13:15:09 EDT
References: <2066@hao.UUCP> <801@oliveb.UUCP> <974@tektools.UUCP> <1631@wucs.UUCP>
Reply-To: richl@tektools.UUCP (Rick Lindsley)
Distribution: net
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 20
Keywords: 4.2BSD restore ctime
Xref: linus net.unix-wizards:14973 net.bugs.4bsd:1765

In article <1631@wucs.UUCP> nz@wucs.UUCP (Neal Ziring) writes:
> 
> In fact, this problem is due to a quirk in a dump/restore, the
> restored files have the correct modification time, but their creation
> times are the time of the restore!
> 

As previously discussed, 4.2 & 4.3 restore do not use the raw disk, so
they cannot maintain the ctime on the files. But changing dump to not
look at the ctime could bite you in a big way -- ctime is changed if
the owner, group, or mode was changed. Looking at the mtime will
guarantee that you have a correct *copy* of the binary, but it may not
be the correct owner, group, or mode! Also, if you link two files together,
the new link won't appear on your dump because changing the link count
changes the ctime, not the mtime.

And of course, the reasons for doing a level 0 dump after a restore have
also been expounded upon in this space.

Rick