From owner-freebsd-bugs Thu Aug 10 11:40: 8 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id F14CB37B9F9 for ; Thu, 10 Aug 2000 11:40:05 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id LAA31518; Thu, 10 Aug 2000 11:40:05 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Thu, 10 Aug 2000 11:40:05 -0700 (PDT) Message-Id: <200008101840.LAA31518@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Jon Masami Kuroda Subject: Re: bin/20445: restore(8) -r and -R don't use mktemp(3) Reply-To: Jon Masami Kuroda Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/20445; it has been noted by GNATS. From: Jon Masami Kuroda To: Sheldon Hearn Cc: Jon Masami Kuroda , freebsd-gnats-submit@freebsd.org Subject: Re: bin/20445: restore(8) -r and -R don't use mktemp(3) Date: Thu, 10 Aug 2000 11:30:14 -0700 I think the only thing that could be done is to add that bit from the NetBSD restore(8) manpage to the FreeBSD one so future young bright file system cloners wont repeat my steps. BUGS restore can get confused when doing incremental restores from dumps that were made on active file systems. A level zero dump must be done after a full restore. Because restore runs in user code, it has no control over inode allocation; thus a full dump must be done to get a new set of directories reflecting the new in- ode numbering, even though the content of the files is unchanged. > 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 would add one more note to that manpage change: This will prevent cloning of filesystems from a single dumpfile to multiple filesystems at one time via "restore -r" or "restore -R". Given time, I could see implementing a -c[lone] flag or the NetBSD TMPDIR environ(7) behaviour, but I think that is well beyond the scope of this PR. ENVIRONMENT If the following environment variable exists it will be utilized by restore: TMPDIR The directory given in TMPDIR will be used instead of /tmp to store temporary files. Refer to environ(7) for more information. Thanks for your time on this one, lets close it. Cheers, Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message