Re: mkisofs gives 'file too large for defined data type' error on 4.3GB file
> > 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
> 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
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
man tar is so sparse ... google ...
Aha, there is a companion for --multi-volume named
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 :)