Hi, > > This does astonish me even more. > > To get an end-of-tape usable with tar > > How does that end-of-tape marker look? Some fixed string?
I guess some kind of graceful, immediate and deterministic i/o error. Lee seems to have a device driver at his /dev/cdrom which can handle sequential DVD+RW writes properly (probably a block device which does random access too). In the old days of magnetic tape i experienced DAT drives (or drivers) which did not work properly with afio's multi-volume capability. They seemed to accept surplus data but did not write them to tape. Quite the same effect as with piping into cdrecord or growisofs and running into an overflow. DC6xxx and TK-50 tapes worked well. Some other DAT too. > > There are projects like Paul Serice's shunt > > or my own one > > (In the most simple case one just needs a filter > > program which stops writing before an overflow > > occurs, asks for the next media and starts a new > > run of growisofs. > > Isn't this simple case already handled by the two programs you > mentioned? If not, it needs to. Not creating dozens of GB of temp data > is a significant time saving. Even more so if the programs you suggest > also handle checksumming. Only speaking for my project : Yes, that simple case is provided as fallback if a compressed afio volume exceeds its predicted size. For producing independent afio volumes or for producing ISO trees my software does some planning in advance in order to create archives or file systems which are small enough to fit on a single media. Writing on the fly is desirable but not always achieveable for various reasons. A buffered write mode and handling of oversized files are provided for those occasions. Checksums are computed. They are urgently needed with DVD media where misburns are not uncommon. Sometimes false data are returned without any error indication by the system. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
