-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Running the FD with debug level 400 might help to see if it generates the SHA1
> at all.

Here's the data for the broken file:

gundabad-fd: find_one.c:357-32 File ----:
/usr/share/postgresql-8.4/man/man7/table.7.bz2
gundabad-fd: backup.c:326-32 FT_LNKSAVED hard link:
/usr/share/postgresql-8.4/man/man7/table.7.bz2 =>
/usr/share/postgresql-8.4/man/man7/with.7.bz2
gundabad-fd: backup.c:424-32 bfiled: sending
/usr/share/postgresql-8.4/man/man7/table.7.bz2 to stored
gundabad-fd: backup.c:1102-32 encode_and_send_attrs
fname=/usr/share/postgresql-8.4/man/man7/table.7.bz2
gundabad-fd: backup.c:1114-32 File 
/usr/share/postgresql-8.4/man/man7/table.7.bz2
attribs=PwA Dky9 IGk C A A A 6 BAA I BMBmj+ BMBmj+ BMBmkF BW A C
attribsEx=
gundabad-fd: backup.c:1133-32 >stored: attrhdr 138 1 0
gundabad-fd: backup.c:1226-32 No strip for
/usr/share/postgresql-8.4/man/man7/table.7.bz2
gundabad-fd: backup.c:1151-32 Link
/usr/share/postgresql-8.4/man/man7/table.7.bz2 to
/usr/share/postgresql-8.4/man/man7/with.7.bz2
gundabad-fd: backup.c:1167-32 >stored: attr len=157: 138 1
/usr/share/postgresql-8.4/man/man7/table.7.bz2
gundabad-fd: backup.c:532-32 do_read=0
gundabad-fd: find_one.c:480-32 FT_LNKSAVED FI=138 LinkFI=86
file=/usr/share/postgresql-8.4/man/man7/with.7.bz2

For comparison, here's an excerpt for an non-broken file:

gundabad-fd: find_one.c:357-32 File ----:
/usr/share/postgresql-8.4/man/man7/with.7.bz2
gundabad-fd: find_one.c:494-32 added to hash FI=85
file=/usr/share/postgresql-8.4/man/man7/with.7.bz2
gundabad-fd: backup.c:333-32 FT_REG saving:
/usr/share/postgresql-8.4/man/man7/with.7.bz2
gundabad-fd: backup.c:424-32 bfiled: sending
/usr/share/postgresql-8.4/man/man7/with.7.bz2 to stored
gundabad-fd: crypto.c:607-32 crypto_digest_new jcr=207b978
gundabad-fd: backup.c:1102-32 encode_and_send_attrs
fname=/usr/share/postgresql-8.4/man/man7/with.7.bz2
gundabad-fd: backup.c:1114-32 File /usr/share/postgresql-8.4/man/man7/with.7.bz2
attribs=PwA Dky9 IGk C A A A 6 BAA I BMBmj+ BMBmj+ BMBmkF A A C
attribsEx=
gundabad-fd: backup.c:1133-32 >stored: attrhdr 86 1 0
gundabad-fd: backup.c:1226-32 No strip for
/usr/share/postgresql-8.4/man/man7/with.7.bz2
gundabad-fd: backup.c:1167-32 >stored: attr len=109: 86 3
/usr/share/postgresql-8.4/man/man7/with.7.bz2
gundabad-fd: backup.c:532-32 do_read=1
gundabad-fd: bfile.c:900-32 open file
/usr/share/postgresql-8.4/man/man7/with.7.bz2
gundabad-fd: bfile.c:924-32 Open file 7
gundabad-fd: backup.c:786-32 Saving data, type=3
gundabad-fd: backup.c:863-32 >stored: datahdr 86 2 0
gundabad-fd: backup.c:1023-32 Send data to SD len=58
gundabad-fd: bfile.c:965-32 Close file 7
gundabad-fd: backup.c:715-32 bfiled>stored:header 86 10 0
gundabad-fd: find_one.c:518-32 FT_REG FI=86 linked=1
file=/usr/share/postgresql-8.4/man/man7/with.7.bz2

I'll make another attempt at interpreting the data:

The broken file is a hard-link (to
/usr/share/postgresql-8.4/man/man7/with.7.bz2). The crypto_digest is only
calculated for the regular file /usr/share/postgresql-8.4/man/man7/with.7.bz2,
but not for the hard link to it.

I assume that the later warnings when doing a differential backup in accurate
mode are due to Bacula erroneously expecting a checksum to be present for hard
links, which it doesn't compute in the first place.

Best,
  Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxEVp4ACgkQk5ta2EV7DoyhTgCeMeWxZJ4810d96X2ZXHV5Pgih
qYkAoKVedcZMfhpCjFKv082yKhlFZC+L
=OCTH
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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