The Hermit Hacker <[EMAIL PROTECTED]> writes:
>See, the real problem that I have with this lack of ability is that it all
>appears to resolve around finding that first position when the backup
>starts ... once its found, its considered "safe" ...
Right. And the problems are:
a) exactly how do we find the first position, and
b) who's got time to implement it absolutely, positively, right?
I'm not saying a) is even particularly hard, just that it has to be done
carefully and not the obvious "fsf and go".
Part b) is, of course, hopeless :-).
>so any delay in the
>backup will happen right at the beginning, while the dumpers are working
>at pulling down data ...
Agreed. That's never been an issue as far as I'm concerned.
Xavier HUMBERT - Labo Informatique <[EMAIL PROTECTED]> writes:
>On WinNt an Macs, that's the way Dantz's Retrospect works for years. I
>never, never, lost a tape.
Fine. How do they do it? Exactly? For every bad thing I can think of
to do to a tape, not to mention what the drive can come up with?
Simon Mayr <[EMAIL PROTECTED]> writes:
>I think I read somewhere that the behavior of amanda has changed about
>the meaning of /dev/null. Amanda didn't let me use the /dev/null device,
>ioctl error or something, cannot rewind, wrong tape etc., so I came up
>with the simply-delete-the-stuff solution ...
Somewhere around 2.4.1 it was changed to treat /dev/null as a special
debugging tool. It faked the places it needed to (e.g. rewind, weof) and
wrote the images to /dev/null just as though they were a real tape, thus
throwing them away. The idea was to use it for testing purposes only.
In 2.5 (and 2.4.2-tapeio/2.4.2-multitape), it changes again and there is
a new "null:" tape driver. Using /dev/null goes back to its old behavior
(of not working :-).
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
