From owner-freebsd-current@FreeBSD.ORG Tue Jul 6 18:13:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6F5816A4CE for ; Tue, 6 Jul 2004 18:13:00 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E7F943D45 for ; Tue, 6 Jul 2004 18:13:00 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i66ICopM004404; Tue, 6 Jul 2004 11:12:54 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200407061812.i66ICopM004404@gw.catspoiler.org> Date: Tue, 6 Jul 2004 11:12:50 -0700 (PDT) From: Don Lewis To: cswiger@mac.com In-Reply-To: <579308A2-CF6D-11D8-911E-003065ABFD92@mac.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org cc: damaker@fillibach.de Subject: Re: moving /usr to another partition X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2004 18:13:00 -0000 On 6 Jul, Charles Swiger wrote: > On Jul 5, 2004, at 5:50 PM, Don Lewis wrote >> I'm pretty sure that "restore -r" will do the right thing and just >> unpack the dump archive into the current working directory. I'm pretty >> sure that I've done this in the past. >> >> I don't understand the warnings in the man page: >> >> -r Restore (rebuild a file system). The target file system >> should >> be made pristine with newfs(8), mounted and the user cd'd >> into >> the pristine file system before starting the restoration >> of the >> initial level 0 backup. > > These warnings are due to the way dump handles files which are hard > linked to each other. > > Basicly, the dump format simply archives the inode # used by a > hard-linked file, and restore depends on being able to use that same > inode # when extracting a tree of files where some of them are > hard-linked to each other. If you restore to a clean filesystem which > was freshly newfs'ed, restore doesn't have to worry about the inodes it > wants to use already being used by other files. When restore extracts the file, the inode is quite likely to be different than before since it is just using open() to create the new file. Restore just has to remember the name of the file so that it can pass it to link() to create the other hard links.