Kern Sibbald wrote:
>> [EMAIL PROTECTED] lib]# ./md5sum /path/to/datfix/20000101.1.dat
>> c4e8a6c211039eae6e94da1620b35581
>>
>> Now compare this to the catalog in Mysql:
>>
>> mysql> select Filename.FilenameId,Path.Path,Filename.Name,File.MD5 from 
>> Path,File,Filename where Filename.Name='20000101.1.dat' and 
>> Filename.FilenameId=File.FilenameId and File.PathId=Path.PathId and Path 
>> like '%/datfix/%';
>> +------------+-------------+----------------+------------------------+
>> | FilenameId | Path        | Name           | MD5
>> +------------+-------------+----------------+------------------------+
>> | 137634 | /original/path/ | 20000101.1.dat | ti/+AnBHiz4yb9YM45/RDB |
>> | 137634 | /original/path/ | 20000101.1.dat | ti/+AnBHiz4yb9YM45/RDB |
>> +------------+-------------+----------------+------------------------+
>> 2 rows in set (0.00 sec)
>>
>> (There are two entries, because we do on and off-site backup runs)
>>
>> How do I get from "c4e8a6c211039eae6e94da1620b35581" to 
>> "ti/+AnBHiz4yb9YM45/RDB" or vice-versa? I think I am stuck.
>>
>> For reference, the standard linux md5sum gives this:
>>
>> [EMAIL PROTECTED] lib]# /usr/bin/md5sum /path/to/datfix/2000/20000101.1.dat
>> b622fe0270478b3e326cd60ce196d10d
>>
>> I have checked all this with some other files, and the behaviour is the 
>> same.
> 
> I guess 1.36.3, which is pretty old is probably missing some code that is in 
> md5.c in the current SVN.  I'll send a second email with the current md5.c 
> attached -- off list.  It *should* compile and run fine in your 1.36.3 code, 
> just save the original for comparison if you run into problems.

Thanks for that Kern.

I had to hack it slightly, since there are now extra arguments to 
bin_to_base64().

Now I get results like this:

[EMAIL PROTECTED] lib]# ./md5sum /path/to/datfix/2000/20000101.1.dat
c4e8a6c211039eae6e94da1620b35581  x++mwhEDn65ul9oWI7NVgB 
/path/to/datfix/2000/20000101.1.dat

So I have the following, which don't match:

1) System MD5sum from file on disk
2) Bacula md5sum, from file on disk
3) Base64 encoding of (2)
4) Base64 hash stored in the catalog

1 and 2 don't match, which is confusing me.

3 and 4 don't match either. I'm rapidly concluding that (4) is just 
garbage, due to whatever nonsense our in-house scripts introduced into 
the system many months ago.

Jon

-- 
Jon Wilson <[EMAIL PROTECTED]>
Systems Administration Manager

PO Box H58, Australia Square, Sydney NSW 1215
Level 2, 9 Castlereagh Street, Sydney Office Tel:+61 9231 5888
Direct Tel:+61 2 9236 9118  Fax: +61 2 9231 5988
www.sirca.org.au

DISCLAIMER: The contents of this email, inclusive of attachments, may be 
legally privileged and confidential. Any unauthorised use of the 
contents is expressly prohibited. If you have received this email 
message in error or are not the intended recipient, you should destroy 
the message along with any attachment(s). Unintended recipients of this 
email are prohibited from retaining, disclosing, distributing or using 
any information herein. This email is also subject to copyright. No part 
of it should be reproduced, adapted or transmitted without the written 
consent of the copyright owner.


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to