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