Greetings all.
	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.

Comments?