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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users