The number of files mismatch bug

Hello,

I believe that I have found the bug that has lead to recent complaints
of Bacula refusing to append to a tape because of a number of files
mismatch of the tape and catalog information.  Oddly enough I found this
almost by accident while rewriting the catalog update code to make it
more robust. 

It appears that Bacula "forgets" that a tape is labeled if the currently
mounted tape is not the tape that Bacula initially selected, but that it
is an acceptable volume.  Once Bacula enters this state (a valid Volume
but not marked as labeled), no Volume positioning updates will be
written to the catalog because Bacula excludes updating the catalog for
an unlabeled Volume.

If this is indeed the source of the recent complaints, it is interesting
because the bug has existed since the very earliest Baculas.

I would much appreciate it if those of you who are having this "file
mismatch" problem would apply the patch (1.32d-10-volfiles.patch), which
is available on Source Forge at:

http://osdn.dl.sourceforge.net/sourceforge/bacula/1.32d-10-volfiles.patch

Applying this patch is highly unlikely to cause any unforeseen problems
(i.e. very low risk).

In version 1.33, I have now substantially rewritten the code that syncs
the catalog with the Volume. It is much more robust than the previous
code and even updates the database when the Storage daemon is killed
during a backup. The above patch is a minimal 1.32d update that does not
include this new more robust code. However, I plan to release version
1.33 in the near future after completing addition of a autochanger scan
feature.

Best regards,

Kern



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl