Skip site navigation (1)Skip section navigation (2)
Date:      28 Oct 2001 17:21:18 -0800
From:      swear@blarg.net (Gary W. Swearingen)
To:        Nils Holland <nils@tisys.org>
Cc:        freebsd-questions@FreeBSD.ORG
Subject:   Re: Funny things to do with tar...
Message-ID:  <jn1yjngs1d.yjn@localhost.localdomain>
In-Reply-To: <20011027121324.O692-100000@jodie.ncptiddische.net>
References:  <20011027121324.O692-100000@jodie.ncptiddische.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Nils Holland <nils@tisys.org> writes:

> Note that I made an ISO-fs of each .tar file first, as
> pervious experiences have shown that burning a "raw" .tar file to CD
> causes problems that manifest themselves that during the extraction
> process tar will not be able to detect the end-of-file, so it will abort
> with a lot of read errors once it has reached the end of the first CD.

So tar's "-L" only works when writing the archive and not when reading?

Could you feed the archive through "dd"?  Wouldn't that either
automatically signal end-of-data or you could give "dd" the size?

> All of this makes the issue extremely complicated: I don't know if the
> data got corrupted during creation of the .tar files, during the burncd
> process, or during the extraction process. Furthermore, I don't know if I
> should probably look for the fault in the CD-RW writer, in the CD-ROM
> drive that read the data, or if I should suspect I have bad CD-RW media.

I'd think you could diff the original with the tar archive files.  I'm
sure you can diff those files (or the ISO files) with what on the CD-RW
disks. Either use "dd" and "diff" (ya gotta be careful with getting only
as much data off the CD as is in the hard disk file since burncd writes
too much) or use something like

    vnconfig -c /dev/vn0a iso-file
    mount -r -t cd9660 /dev/vn0a /mnt/tmp
    mount /cdrom
    diff -r /mnt/tmp /cdrom

> All I know is that a backup process like this is not a good thing to use
> for actually backing up important files.

Some seemingly trustworthy/knowledgeable person here has said that only
dump/restore should be trusted (something about file attributes).  I've
seen errors from tar not being able to archive some /dev file with a
too-large device node number.  (Maybe 0x20000000 = /dev/sa0.ctl)


I have used the archiver "afio" which doesn't have tar's no-eof problem
which you mentioned (see -s option) and which does less risky
compression (files, not archives) and which does original-to-archive
comparison.  I've done a little round-trip fidelity testing of it and
tar but I can only say they both seem OK.  During my backups, I have it
compare the original with the tape and it only complains about files
that I know change on a minute-to-minute basis.   But I do wonder if
such a little-used program doesn't have some bugs when even gnu tar is
said to have some.  I've only had to recover from it (a whole OS) once
a few years ago under Linux.  Some testing I've mostly forgotten led
me to believe that something I archived under Linux didn't restore
perfectly under FreeBSD (but I even forget if it was tar or afio or
both).

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?jn1yjngs1d.yjn>