>>>>> On Thu, 08 Jul 2010 18:19:49 +0200, Andreas Koch said: > > with FI=137 occuring in the two log lines > > gundabad-dir: catreq.c:407-25 UpdCat VolSessId=12 VolSessT=1277829932 FI=137 > Strm=1 data_len=123 > ... > gundabad-dir: catreq.c:407-25 UpdCat VolSessId=12 VolSessT=1277829932 FI=137 > Strm=10 data_len=20 > > The broken file table.7.bz2 has FI=138, which shows up only _once_ in the log > (excerpt from first log fragment in this mail) > > gundabad-dir: catreq.c:407-25 UpdCat VolSessId=12 VolSessT=1277829932 FI=138 > Strm=1 data_len=157 > > Nowhere does a line mentioning FI=138 and Strm=10 occur. Instead, at the usual > position (after the missing Digest line), the Cached ... line already mentions > FI=139 and Strm=1: > > gundabad-dir: catreq.c:407-25 UpdCat VolSessId=12 VolSessT=1277829932 FI=139 > Strm=1 data_len=117 > > I hope this info and my attempts at interpretation are helpful!
Yes, that was very useful. Strm=1 is the main attribute info and Strm=10 is the SHA1 digest. I would expect Strm=10 to occur after Strm=1 for each value of FI. It looks like the Director isn't receiving the SHA1 for the broken file. The FD generates the SHA1 and sends it to the SD, which then writes it to the volume and sends it to the Director. Running the FD with debug level 400 might help to see if it generates the SHA1 at all. __Martin ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
