Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site oliveb.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!hplabs!oliveb!jerry
From: jerry@oliveb.UUCP (Jerry Aguirre)
Newsgroups: net.unix-wizards,net.bugs.4bsd
Subject: Re: 4.2BSD restore(8)
Message-ID: <801@oliveb.UUCP>
Date: Tue, 22-Apr-86 11:58:46 EST
Article-I.D.: oliveb.801
Posted: Tue Apr 22 11:58:46 1986
Date-Received: Thu, 24-Apr-86 04:59:36 EST
References: <2066@hao.UUCP>
Reply-To: jerry@oliveb.UUCP (Jerry Aguirre)
Distribution: net
Organization: Olivetti ATC; Cupertino, Ca
Lines: 18
Keywords: 4.2BSD restore ctime
Xref: watmath net.unix-wizards:17765 net.bugs.4bsd:2066

I have also noticed that after a restore all the files marked as
changed and will go on the next dump.  The 4.2BSD restore works on the
mounted file system.  This simplifies the dump code and partial
restores but makes it impossible to correctly update the time stamps on
the file.  Previous versions of restor used the raw file system and
could write any information it wanted.

Remember that dump will use the ctime, not the mtime, when deciding
what files to dump.  There is no system call to backdate the ctime on a
mounted file system.

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.  Besides additional down
time the new level 0 also messes up the dump schedule.

					Jerry Aguirre @ Olivetti ATC
{hplabs|fortune|idi|ihnp4|tolerant|allegra|glacier|olhqma}!oliveb!jerry