--nextPart2814839.qx05Vb5oxd
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Tue, 26 Feb 2008, Alex Zbyslaw wrote:
> 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.=20
> Might have trouble accessing /dev/tty - not sure.
The general solution would be nicer, then you could compress & encrypt.
Although I'm not sure it's so simple as adding SIGPIPE because at the=20
end of the media the compressor will be holding some data that it has=20
read but will never make it out to the media..=20
The only way I could think to solve this was to add an argument that=20
specified a pipeline to stick after the data is generated but before=20
it's fed to the output, although even then it gets a bit gnarly..=20
=2D-=20
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
--nextPart2814839.qx05Vb5oxd
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
iD8DBQBHw2Bx5ZPcIHs/zowRAt2pAJkBECSy5V18ViClTVmTLGsOFh4CMgCfYM12
mC3Z80jz3UweyfhAVSncFUA=
=kbOz
-----END PGP SIGNATURE-----
--nextPart2814839.qx05Vb5oxd--