Re: mkisofs gives 'file too large for defined data type' error on 4.3GB file

[scdbackup@gmx.net]

Hi,

> > I do not know wether tar needs a neat EOF from the media
> > [...]
> 
> Actually, if reading from a named pipe instead of the device, it works OK. 
> Then just put in disc 1, 'cat /dev/dvdrw > named-pipe', and on another 
> terminal 'tar -t -f /named-pipe --multi-volume'.  When the output ends from 
> the cat command, tar asks for the next volume, so the next disc goes in and 
> cat sends the disc data to the pipe to continue the multi-volume archive!  It 
> works pretty good!

This astounds me a bit.
Whatever, if it does work for you and stands all
your tests: Congrats.


To my own experience the CD-ROM drivers of Linux return
a more or less arbitrary number of extra bytes at the
end of the media. Not much, but still enough to spoil
a neat seamless volume change.
With afio or uncompressed tar the reading archiver might
get back on track after a few extra kB. With gzipped tar
you will not get happy any more afterwards.

With DVR[+-]RW it is even worse since most read drivers
return a substantial amount of extra bytes. Usually up to
the highest byte count that was ever written to that media.
Sometimes even up to the full (unwritten) capacity of the
media.


> I'm getting tar to output to a named pipe.  I just do a 'growisofs -Z 
> /dev/dvdrw=/bak/dvd-bak.pipe' and it works fine.  when tar asks for the next 
> 'tape', I just put in a new disk and execute the same command and it works
> great.

Can it be you rely on growisofs not to read more bytes
from the pipe than it can write to the media ? Given
the new ring buffer in 6.0, i would say this is a
daring assumption.

man tar is so sparse ... google ...
http://www.gnu.org/software/tar/manual/tar.html#Using-Multiple-Tapes
Aha, there is a companion for --multi-volume named
--tape-length= .
That might be a cleaner way to deal with the problem.
Did you already use that option ?

I read there:
"Each volume of a multi-volume archive is an independent tar
 archive, complete in itself."
That might explain why you have no problems with the 
extra bytes when reading.

So i believe it is not like:
> When the output ends from
> the cat command, tar asks for the next volume,
but rather that tar ends reading the volume after
encountering its volume/archive end mark and opens
a new communication channel via the named pipe
object for the next volume. The old cat command then
probably dies from broken pipe.

Nevertheless, a nice stunt.


Have a nice day :)

Thomas