I've been able to reproduce this situation reliably.  I'm using an autochanger 
on FreeBSD 8.x within Bacula 5.0.3.

* Let a job start and ask for a new tape (in my case, part of the job writes to 
an existing tape)
* Don't give Bacula the tape it is asking for
* label a new tape
* Bacula grabs it and starts writing to it immediately
* while the job continues, run the update slots command

Verify that the slot number has been updated in the database:

bacula=# select volumename, slot from media where slot <> 0 order by slot;
 volumename | slot 
------------+------
 ETU022     |    1
 ETU044     |    2
 ETU047     |    9
 ETU026     |   10
(4 rows)

Wait a while.  Then verify again:

bacula=# select volumename, slot from media where slot <> 0 order by slot;
 volumename | slot 
------------+------
 ETU022     |    1
 ETU047     |    9
 ETU026     |   10
(3 rows)


Run update slots again.  Verify. Wait... this can be repeated several times 
throughout the job.

My suspicion, yet to be verified: the UPDATE command being run as the job 
progresses is setting the slot column when it should not be.

-- 
Dan Langille
http://langille.org
------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users