From owner-freebsd-stable Wed Apr 28 15:32:23 1999 Delivered-To: freebsd-stable@freebsd.org Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by hub.freebsd.org (Postfix) with ESMTP id DAE4415793 for ; Wed, 28 Apr 1999 15:32:09 -0700 (PDT) (envelope-from naddy@mips.rhein-neckar.de) Received: from mips.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id AAA06981 for freebsd-stable@freebsd.org; Thu, 29 Apr 1999 00:32:08 +0200 (CEST) (envelope-from naddy@mips.rhein-neckar.de) Received: by mips.rhein-neckar.de id m10cc6p-000WycC (Debian Smail-3.2.0.101 1997-Dec-17 #2); Wed, 28 Apr 1999 23:43:11 +0200 (CEST) From: naddy@mips.rhein-neckar.de (Christian Weisgerber) Subject: Re: Does tar do sparse files these days Date: 28 Apr 1999 23:43:08 +0200 Message-ID: <7g7vdc$3e6$1@mips.rhein-neckar.de> References: <199904280102.VAA02170@mailfw1.ford.com> To: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian O'Connor. CF583173 HO 2nd Floor wrote: > In the dim dark days of yore(90-91) I was advised not to do full backups > using tar. There were problems with sparse files, and device files etc. There still are. GNU tar, which FreeBSD uses, can't handle 32-bit dev_t. Apparently this is a limitation of the archive format. naddy@bigeye[~] tar cf /dev/null /dev tar: Removing leading / from absolute path names in the archive. tar: /dev/da0s3: minor number too large; not dumped tar: /dev/da0s4: minor number too large; not dumped tar: /dev/rda0s3: minor number too large; not dumped tar: /dev/rda0s4: minor number too large; not dumped Sparse files are a special case. You *cannot* reliably recognize sparse files through the file API. The state of the art, which you get when you invoke GNU tar with the -S option, is to compare stat.st_blocks with the file size. If there are fewer blocks than you'd expect from the size, there obviously must be holes somewhere, and you can now take guesses which large ranges of null bytes might be holes. This should work for most real world cases, but no way are you going to be able to exactly reproduce a file that freely intermixes holes with actual blocks of null bytes. -- Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de carpe librum: books 'n' reviews To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message