emulate an end-of-media
xfb52 at dial.pipex.com
Mon Feb 25 22:00:48 UTC 2008
Mike Meyer wrote:
>On Mon, 25 Feb 2008 21:19:33 +0100 "Martin Laabs" <martin.laabs at mailbox.tu-dresden.de> wrote:
>>On Mon, 25 Feb 2008 20:34:31 +0100, wrote:
>>>You might want to play with the -P option to dump. Your above could be
>>>dump -aL0 -P 'compress -c' /MYFILESYSTEM | cdrecord dev=... -
Why compress? It's ancient technology and will be vastly outperformed
by gzip (and bzip2 but that's slower).
>>>Assuming that compress -c & cdrecord play nice (which your magic
>>>device solution also requires)
>>My solution can just close the pipe at the one "end" of the magic
>>device which would be realy simple to implement in a script.
>While you're proposing a magic device that catches sigpipe, and
>delivers an EOM to make dump -a happy. I'm proposing that dump catch
>the sigpipe, and treat it like an EOM if it has -a. This may be
>non-workable, in that you have to be able to tell if it was the -P
>process or a slave process that generated the sigpipe, but I think
>it's the best solution.
Are there not (at least) two more alternatives?
1) Add gzip/zlib support to dump. That would seem easier than new
devices. Then -a would just work.
2) Instead of using cdrecord directly you have a wrapper which
"emulates" the dump -a behaviour by writing 650/700Mb of data using
cdrecord then prompting for the next cd. You don't close the pipe, and
dump should just block waiting for your "device" to be ready. Might
have trouble accessing /dev/tty - not sure.
More information about the freebsd-hackers