@adriansev : well, you still need to ask the copy job to do the checksum:

[2020-04-03 22:00:39.992457 +0300][Dump ][Utility ] Adding job with properties: 'checkSumMode' = 'none', 'checkSumPreset' = '', 'checkSumType' = '', 'chunkSize' = '8388608', 'coerce' = '0', 'dynamicSource' = '0', 'force' = '0', 'initTimeout' = '600', 'makeDir' = '1', 'parallelChunks' = '4', 'posc' = '1', 'preserveXAttr' = '0', 'source' = '/home/adrian/tmp/f26e8b0c-c2c1-5b2e-809d-f703ba4f61f6.meta4?xrdcl.unzip=AnalysisResults.root', 'target' = '/home.hdd/adrian/work-GRID/jalien_py/md5_test/AnalysisResults.root', 'thirdParty' = 'none', 'tpcTimeout' = '1800', 'xcp' = '0', 'xcpBlockSize' = '134217728', 'xrate' = '0', 'zipArchive' = '0'

please set checkSumMode to end2end and checkSumType to md5 (I suppose ;-)

Maybe it would be a good idea to run first a test with plain xrdcp.

To explain more the mechanics, if you want the client to do the checksumming you always need to give it the checkSumMode and checkSumType. For normal files (not extracted from ZIP) using the checksum from a metalink was already supported.
Files extracted from ZIP are special because one would expect that the checksum in the metalink refers to the whole ZIP archive and not to the extracted file and that's why by default we say that checksumming for those files is not supported (expect zcrc32, but that's a different story).
The ZipMtlnCksum setting allows you to out rule the default behaviour and assume that the checksum provided in the metalink is actually for the extracted file (which I believe is true in your case). I hope now it's more clear.

Answer your second question: the ZipMtlnCksum has no effect on normal files (not extracted from ZIP archives).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1