Christopher J.Walker wrote:
> Jensen, J (Jens) wrote:
>> On 29/06/2011 00:05, Christopher J. Walker wrote:
>>> Checksums seem to have identified a corrupt file at QM. The checksum
>>> that the file is supposed to be doesn't match the actual checksum of the
>>> file.
>>>
>>> I can declare the file as lost - and ought to check the other files on
>>> that disk server I guess.
>> Who owns it?
>
> CMS
>
>> Do they have other replicas of the file?
>
> Probably not, but I'll file a GGUS ticket to check.
>
Should Adler32 checksums include the leading zero?
I'm checking through the disk to see if we have other errors.
Can someone with ATLAS permissions tell me what the checksum of
srm://se03.esc.qmul.ac.uk/atlas/atlasdatadisk/step09/AOD/closed/step09.20201127000278L.physics_B.recon.AOD.closed/step09.20201127000278L.physics_B.recon.AOD.closed._lb0002._0001_1309790821
Should be.
Options are:
cfbcbb1 (storm's gsi enabled gridftp)
or
0cfbcbb1 (the script from bestman)
Note the difference in leading zero.
Chris
>> I noticed we didn't have a suggested approach so I wrote one:
>> http://www.gridpp.ac.uk/wiki/File_Integrity_Testing#Goal_5:_How_to_deal_with_corrupted_files
>>
>> Does it make sense?
>>
>> Cheers
>
> And what do I find in my inbox shortly afterwards - and article on
> "Checksumming Files to Find Bit-Rot"
>
> http://www.linux-mag.com/id/8794/?hq_e=el&hq_m=1280622&hq_l=10&hq_v=d6167fe3ed
>
>
> Chris
|