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