bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

["Davide G. M. Salvetti" <address@hidden>] tar; Option --tape-length sho


From: Davide G . M . Salvetti
Subject: ["Davide G. M. Salvetti" <address@hidden>] tar; Option --tape-length should be used when reading archive as well.
Date: Sat, 28 Sep 2002 11:35:58 +0200
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu)

[Please, keep address@hidden in Cc if/when you reply.]

Hi,

I'm forwarding a wishlist bug I filed against the Debian tar package a
while ago.

-- 
Salve, | GNU PG (GPG) Key ID: 9396865D
Davide | <http://www.linux.it/~salve/>
--- Begin Message --- Subject: tar; Option --tape-length should be used when reading archive as well. Date: Fri, 01 Feb 2002 13:51:51 +0100
Package: tar
Version: 1.13.25-1
Severity: wishlist

Hi,

this wishlist bug should be probably forwarded upstream.

I'd like to have a way to instruct tar about the size of each volume of a
multivolume archive not only while writing, the way --tape-length currently
does, but also while reading; i.e., I'd like to have an option (which should
probably be --tape-length) to tell tar: "Hey, this multivolume archive has
volumes no longer than X bytes, no matter where you think EOF is on the device
you're reading from".

That would allow me to use tar to do multivolume backup with CD-R, and easily
restore from them.  In the current situation, in fact, one may do a multivolume
backup to CD-R with tar, but restoring from it is very painful.

The fact is, that when directly writing to CD-R (with no filesystem), at least
with Linux, you seem to have to pad the track with a certain number of zero
blocks at the end (128 * 2048 apparently works reliably for me), otherwise you
won't be able to read the data back.  What I mean is that you have to do
something like

        tar --create --file=- /somedir | cdrecord -data padsize=128s -

if you hope to do something like "tar xf /dev/cdrw" successfully after; (in
this example, I'm deliberately setting aside multivolume issues, to make the
matter simpler).  If you don't add the right padsize, tar (as well as dd, FWIW)
won't be able to read the last n blocks of the track, where n is a small
integer (I'm not sure what the limit is); padding a bit solves this problem
(128s = 128 * 2048 bytes seems the right size for me), because you don't need
to read those blocks anymore to restore the whole archive.

However, if you add the padding to a multivolume archive and then you try to
restore it with something like "tar xMf /dev/cdrw", there is no way to tell tar
to change volume after that many blocks; as I understand it --tape-length
actually works only while writing (it doesn't seem to do anything good when
reading).  This raises my problem, 'cause tar doesn't stop at the end of the
archive, and pretends to read the padding as well; since the padding is made up
of zeroes, tar thinks the archive ends at the first volume and stops there.  If
one adds "--ignore-zeros" to the option list of tar, tar doesn't stop at the
zero blocks after the end of the archive, but it happily adds them to the last
file of the first volume until it gets reading errors (which happens, as stated
above, when you try to access the last blocks of the track); then it asks for
the next volume, but isn't able to continue, yelling "the volume is out of
sequence", which is probably due to loss of synchronization on the cross volume
file.

So the only way I was able to find to recover such a multivolume archive
consists in copying each volume with dd somewhere, telling dd the exact size of
each volume, and the running tar with multiple --file options, like

              dd if=/dev/cdrw of=/tmp/1.tar bs=2048 count=333000
              dd if=/dev/cdrw of=/tmp/2.tar bs=2048 count=333000
              ...
              dd if=/dev/cdrw of=/tmp/n.tar bs=2048 count=333000

and then

      tar --extract --multi-volume --file=/tmp/1.tar --file=/tmp/2.tar \
          ... --file=/tmp/n.tar

Obviously, one must have enough free space somewhere to be able to do something
like this, which may be very impractical.

BTW, I couldn't get a way to do the work with named pipes; I thought something
like

        mkfifo /tmp/pipe
        tar --extract --multi-volume --file=/tmp/pipe

and (from another shell)

        dd if=/dev/cdrw of=/tmp/pipe bs=2048 count=333000
        dd if=/dev/cdrw of=/tmp/pipe bs=2048 count=333000
        ...
        dd if=/dev/cdrw of=/tmp/pipe bs=2048 count=333000

could have worked, but it doesn't, moreover in an inconsistent way: depending
on something I don't fully understand, sometimes tar reads the volume,
sometimes it doesn't read anything, but ask for next one, etc.  I could
experiment more on this if someone could give me some more clues.

I think that adding on option to tar to specify the length of each volume would
very cleanly solve this mess: if tar stopped after that many bytes, records,
blocks, whatever you want, without reading the zero padding at the end of the
tracks, I think all would be well, and it would ask you the next volume
continuing without problems.

On the other hand, perhaps the best thing to do would be if tar could record
each volume length somewhere in the archive, for example in the volume label:
that way one would not have to remember what it was, and the new option might
not be necessary anymore, since tar itself would know for sure how many records
to read.  (Having some way to manually override this won't be bad, however: no
program should be clever than the person who runs it.)

Many thanks!

P.S. While I could use afio in the meanwhile, workarounds would be very much
appreciated: I'd really like to get tar working.


-- System Information
Debian Release: 3.0
Kernel Version: Linux HAL 2.4.17 #1 Mon Jan 28 22:07:22 CET 2002 i586 unknown

Versions of the packages tar depends on:
ii  libc6          2.2.4-7        GNU C Library: Shared libraries and Timezone




--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]