On Wed April 9 2008 5:08:47 am Wouter Verhelst wrote: > (first, I'm not sure whether this is the right package to submit > against; feel free to reassign if necessary).
They are all (except -doc) built from the same source, and all wind up in my INBOX in any case :-) > When a bacula tape becomes inconsistent with what bacula has recorded > about that particular tape, for any reason (e.g., when there was an > error writing to the database because the disk filled, or when the > director crashed when a backup job was in progress), then bacula will > mark the tape as being 'in error'. This makes it impossible to > distinguish between such a case and a case of a /real/ tape error. > > It would probably be best to create a new state, 'Inconsistent' or some > such, to be assigned to tapes of which the data as stored in the > database does not correspond to the data as found on the tape itself. > This would make it easier for a system administrator to figure out what > the correct course of action is when a failure occurs (e.g., manually > recycle the tape, or throw it away in case of a /real/ error). This is pretty obviously an upstream design decision. I would be willing to forward this upstream, but it's reported against a very old version. I am not set up to be able to test this particular behavior on the current Bacula 2.2.x, so I don't know for sure what the current behavior is. Would you be willing to either a) test 2.2.x and report back on its behavior, or b) take this discussion to a Bacula mailing list yourself, and we close the Debian bug with a pointer to the thread? -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
