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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
