John R. Jackson wrote:
> >OK. That means you have a "process in the middle" that saves stdin to
> >a file and only starts outputting to stdout once it gets a signal.
>
> We cannot assume we have file space on the client. I suspect it would
> be easier to just load up the blocks in memory, but that then implies
> a potential for a lot of memory use.
Hmm. Why not run this on the server then?
> >The restart would simply be done the "old fashioned" way, right?
>
> Yes, although with all the extra protocol it would have to understand
> this is a "real" dump, not an estimate.
Yep.
> > tar cvf /dev/null /cdrom
> >
> >to verify if all data-blocks on the CDROM are readable. Fooled you!
>
> This should work:
>
> tar cvf - /cdrom | cat > /dev/null
Oh yes, I sure know the workaround.
I just happened to be paying attention that the tar command of a 600M
CD was taking WAY too little time, and investigated.
Otherwise I could have thrown away the originals after having verified
that the CD came out just fine, although my CD-burn complained a
bit...
This was just a bit "too close for comfort".
Tar ALWAYS reads all the data, and not reading the data is too much of
a surprise. It's fine with me if there is a
--optimize-if-reading-data-is-not-neccesary option. But automatically
doing this if the output file is specified as /dev/null, feels like
bad stuff.
Suppose I happen to be non-english, and somehow I like my tape drive
called "null". Then what? (ok. the whole system grinds to a halt, but
suppose I recompile ld.so, glibc and stuff to use /dev/0 instead...)
Anyway, can't change this anymore now. Just a lesson in "clean
design". This was a mistake. IMHO.
Roger.
--
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
