From owner-freebsd-questions Thu Dec 26 07:15:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA23613 for questions-outgoing; Thu, 26 Dec 1996 07:15:32 -0800 (PST) Received: from mail.ka.inka.de (quechua.inka.de [193.197.84.5]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA23608 for ; Thu, 26 Dec 1996 07:15:29 -0800 (PST) Received: from phoenix.inka.de ([193.197.85.1]) by mail.ka.inka.de with smtp (ident root using rfc1413) id m0vdHWn-0004FaC (Debian Smail-3.2 1996-Jul-4 #2); Thu, 26 Dec 1996 16:15:25 +0100 (MET) Received: from mips.pfalz.de by phoenix.inka.de with bsmtp (S3.1.29.1) id ; Thu, 26 Dec 96 16:15 MET Received: by mips.pfalz.de (Smail3.1.29.1 #6) id m0vdFKE-000CmsC; Thu, 26 Dec 96 13:54 CET Message-Id: From: naddy@mips.pfalz.de (Christian Weisgerber) Subject: Re: cpio truncating inode numbers? To: questions@freefall.freebsd.org Date: Thu, 26 Dec 1996 13:54:15 +0100 (CET) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Greg Lehey writes: > > cpio: xxxxx filename being backed up : truncating inode number > > It's not a disaster, it's a historical quirk. The cpio format has > only 2 bytes for the inode number (the inode is the real file > description; the file names in the directories just point to the > inode). I've forgotten why it's there in the first place, and since > inodes have gone to 4 bytes, any large disk will have lots of inode > numbers which won't fit in two bytes. You don't need the inode number > when restoring the files, so you don't need to worry (but it sure is a > nuisance :-) I thought the reason it's included is in order to be able to restore hard links. Otherwise you'll end up with two copies of the same file. If I'm right, this isn't a disaster but not particularly nice either. You'll also run into problems backing up /dev. The GNU cpio FreeBSD uses supports several formats with the -H option. "-H crc" (evil SVR4, CRC-protected) looks like a good choice to me. See the man page. > You're probably better off using tar. What's the maximum path length GNU tar can handle? 100 characters? 250? -- Christian 'naddy' Weisgerber naddy@mips.pfalz.de See another pointless homepage at . -- currently reading: Peter F. Hamilton, The Reality Dysfunction --