Subject: design problem with restore(8)?
To: None <current-users@NetBSD.ORG>
From: Luke Mewburn <firstname.lastname@example.org>
Date: 06/17/1996 16:56:58
A few days ago I submitted a patch (bin/2544 I think) that
documents how I feel that restore(8) is broken with respect to
restoring from dumps that were created at the same time.
The problem comes down to restore using the dumpdate as name for the
temporary file. This bites you (because the process unlinks the
temporary files when finished) if you are:
- doing operations on different dumps that were started at the
same second, such as two extractions (I've had this happen...)
- extracting from a file, and listing the contents of that
same file in another window
I attempted to solve these problems by using mktemp(3). Unfortunately,
there seems to be a case where the 'rstmode' file is expected to exist
where the current process doesn't create it - the 'R' flag which
allows you to restart restoring a multi-volume archive that was
started with the 'r' flag. I've never used this option, and in attempting
to reproduce how this works, I couldn't. (user error probably ;-)
I believe that fixing the original problem is more important,
however supporting 'r'/'R' is also a Good Thing.
My proposal is (which I'll send-pr unless I get a good case against):
- all operations except 'r' and 'R' use a temporary
per-process filename, (i.e, operations which aren't intended
to be restarted)
- 'r' and 'R' only use the dumpdate as the temporary filename
(so they can be restarted and pick up the correct bit)
- document the above.
This doesn't break current things and fixes up 99% of cases where
sharing the tempname causes problems.