Date: Tue, 8 Aug 2000 11:10:04 -0700 (PDT) From: Jon Masami Kuroda <jkuroda@eecs.berkeley.edu> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/20445: restore(8) -r and -R don't use mktemp(3) Message-ID: <200008081810.LAA59613@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/20445; it has been noted by GNATS.
From: Jon Masami Kuroda <jkuroda@eecs.berkeley.edu>
To: Sheldon Hearn <sheldonh@uunet.co.za>
Cc: Jon Masami Kuroda <jkuroda@eecs.berkeley.edu>,
freebsd-gnats-submit@freebsd.org
Subject: Re: bin/20445: restore(8) -r and -R don't use mktemp(3)
Date: Tue, 08 Aug 2000 11:01:10 -0700
Aha, I found out why and I didnt even have to talk to Luke yet! =)
From the NetBSD restore(8) manpage:
The temporary files /tmp/rstdir* and /tmp/rstmode* are generated with a
unique name based on the date of the dump and the process ID (see
mktemp(3)), except for when -r or -R is used. Because -R allows you to
restart a -r operation that may have been interrupted, the temporary
files should be the same across different processes. In all other cases,
the files are unique because it is possible to have two different dumps
started at the same time, and separate operations shouldn't conflict with
each other.
I found this while going through the NetBSD cvsweb stuff where I found
revision 1.20 of dirs.c and traced my way to the man page.
http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/basesrc/sbin/restore/dirs.c
Now this makes sense. It's still annoying, but it makes sense. Perhaps
restore(8) needs a flag to say "screw this, use mkstemp!" if the operator
so desires. Or a way to save the names of the files for later use.
--Jon
Sheldon Hearn wrote on Tue, 08 Aug 2000 12:16:39 +0200:
:
: On Mon, 07 Aug 2000 09:37:22 MST, Jon Masami Kuroda wrote:
:
: > This "bug" should not have any security impact if I understand open(2)
: > and the "O_EXCL" flag correctly. It is, so far, just a productivity
: > annoyance.
:
: While that's certainly the way it looks to me, I'm very uncomfortable
: with proceding without finding out _why_ OpenBSD's rev 1.3 was required.
: Essentially, your patch proposes that we revert NetBSD's rev 1.3. The
: CVS log for that delta implies that the patch you propose will somehow
: break the -r and -R options.
:
: I'm not sure whether <lukem@supp.cpr.itg.telecom.com.au> is still a
: deliverable address. Perhaps you could chat to Theo and ask him why the
: revision was introduced in the first place?
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008081810.LAA59613>