Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site onfcanim.UUCP
Path: utzoo!watmath!watnot!watcgl!onfcanim!dave
From: dave@onfcanim.UUCP (Dave Martindale)
Newsgroups: net.unix-wizards,net.bugs.4bsd
Subject: Re: 4.2BSD restore(8)
Message-ID: <14840@onfcanim.UUCP>
Date: Fri, 2-May-86 19:07:55 EDT
Article-I.D.: onfcanim.14840
Posted: Fri May  2 19:07:55 1986
Date-Received: Sat, 3-May-86 19:15:58 EDT
References: <2066@hao.UUCP> <801@oliveb.UUCP> <974@tektools.UUCP> <1631@wucs.UUCP>
Reply-To: dave@onfcanim.UUCP (Dave Martindale)
Distribution: net
Organization: ONF, Montreal
Lines: 42
Keywords: 4.2BSD restore ctime
Xref: watmath net.unix-wizards:17903 net.bugs.4bsd:2080
Summary: 

In article <1631@wucs.UUCP> nz@wucs.UUCP (Neal Ziring) writes:
> > > I have also noticed that after a restore all the files marked as
> > > changed and will go on the next 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
> >  ...
>
>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!
>
>Repeat-By:
>	Put a file system on a dummy partition, and do a level 0
>	dump(8) of it.  Wait a few minutes.  Then, trash the partition
>	and restore it fully from your dump.  Change one file.
>	Now, do a level 1 backup with dump(8).  The backup should be
>	extremely small (one file) but it isn't!  It is the whole
>	filesystem!
>
>To Fix:
>	Change dump so that it looks only at the modification time, not
>	the creation and modification times.
>

If you think of a dump as "all the files that have changed *contents* since
the most recent higher-level dump", then you do indeed want to dump
according to modification times.  But this is **not** what dump was
written to do.  It is intended to write out *all* the information needed
to restore *all* changes made to the filesystem, including changes
in permissions or link count of a file.  These latter things change
the inode's "di_ctime", which is really "change" not "create" time.

So, if you want to use dump and restore as a method of completely restoring
the state of a filesystem, not just getting back all the contents of the
files, don't change the algorithm.

And if you run 4.[23] BSD, you will still have to do level 0 dump after
doing a full restore.  No way of avoiding it.

	Dave Martindale