Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!pyramid!hplabs!tektronix!tekgen!tektools!richl
From: richl@tektools.UUCP
Newsgroups: net.unix-wizards,net.bugs.4bsd
Subject: Re: 4.2BSD restore(8)
Message-ID: <974@tektools.UUCP>
Date: Wed, 23-Apr-86 00:54:06 EST
Article-I.D.: tektools.974
Posted: Wed Apr 23 00:54:06 1986
Date-Received: Sat, 26-Apr-86 03:26:22 EST
References: <2066@hao.UUCP> <801@oliveb.UUCP>
Reply-To: richl@tektools.UUCP (Rick Lindsley)
Distribution: net
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 18
Keywords: 4.2BSD restore ctime
Xref: watmath net.unix-wizards:17791 net.bugs.4bsd:2068

In article <801@oliveb.UUCP> jerry@oliveb.UUCP (Jerry Aguirre) writes:
> I have also noticed that after a restore all the files marked as
> changed and will go on the next dump.  [ ... ]
> 
> Procedurally this is a crock as after spending X hours of down time
> restoring the file system, you have to turn around and spend Y
> additional hours doing a new level 0 dump.

If you really did just spend hours restoring the file system, then you
have restored all or virtually all of the file system. If you don't
want to do a level 0 dump, simply edit /etc/dumpdates to reflect
whatever time you want dumps taken from. If you just restored the entire
file system you have the entire system on tape anyway; so you won't
miss anything by this.

Rick Lindsley
richl%tektools@tektronix.csnet
...!{ihnp4,decvax,cbosgd}!tektronix!tektools!richl