Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds

[Joerg Wunsch]

After finally migrating my Bacula database from SQlite into PostgreSQL
in the course of upgrading the machine to new hardware as well as from
FreeBSD 8.2 to 10-stable, Bacula now experiences strange behaviour:

The number of files mismatch! Volume=32767 Catalog=33
Correcting Catalog

What happens is that Bacula, when trying to go to end of recorded
medium, issues the equivalent of

mt fsf 32767

and then

mt status

in order to know which tape file it is located at.

In FreeBSD 8.2, this correctly yielded the actual tape file number
(i. e., 33 in the above case), but in FreeBSD 10, it yields 32767.
You can perform "mt fsf" ad nauseum now, and each time, it pretends it
were advancing one more file ...

I did a glance at the source code differences between 8.2 and 10.x,
but nothing sprang into my eye immediately.  Does anyone have an
idea?

Anyone out there who can test this on their machines?

(One other change is that the machine turned from i386 into amd64
architecture, so there's also a minor chance the problem might be
64-bit related, although I wouldn't assume this to be the case.)
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)