Re: bin/52432: /etc/dumpdates format egregious

[Greywolf <greywolf%starwolf.com@localhost>]

Hi, Robert,

[I wrote]:
| > Restore uses restoresymtable to determine whether or not the
| > incremental restore is of the proper date.

[You replied]:
|  That file is more for deleting files that were deleted before one dump
|  and the incremental that follows, if it also serves to check that the
|  correct incremental is being restored, that's news ... but I am not sure
|  how it really can (except perhaps to make sure that one from earlier
|  than the previous restore is not attempted) - it is built from the
|  contents of the level N dump when it is restored, and so can only possibly
|  have info that existed when that dump was done - what the next dump level
|  would be, for the next incremental, cannot possibly be known then, nor is
|  it really possible to tell if a level is skipped in the restore sequence,
|  as only the changes get dumped, and all the changes do, but when we come
|  to a restore, we (ie: restore) cannot tell if a dir/inode is not on the
|  backup because it was never changed (between previous and current) or
|  whether it was changed, but backed up onto an intermediate level dump that
|  happened between the one that has already been restored, and the one that
|  is now about to be - except in some quite rare cases (that is, nothing that
|  we can rely upon.)

Here's my understanding:

The restoresymtable contains, among the inode map and such:

* the device which was dumped,
* possibly the filesystem name associated with the device (if it can figure
  it out),
* possibly a dump label (optional),
* the level of the dump last restored from,
* the date of said dump (the day the files were dumped on),
* the date SINCE files were dumped (i.e. the date of the previous dump,
  which would have shown on the screen during the dump as
  "Date of last level <X> dump:").

If you do a level 0 full restore (-r), with the intention of doing an
incremental restore (handling deletions/moves), your next restore MUST
come from a dump whose last-dumped-from date matches the date of the
level 0, and so on, or the incremental restore will fail.

If an incremental restore depended on /etc/dumpdates, we'd never be able
to get an integral incremental restore of the root filesystem, nor any
other filesystem thereafter if we needed to restore the whole thing,
because the relevant information to the current dump wouldn't be available
until it finished.