I see xrdadler32 thinks that log.18890879.000052.log.tgz is the host name. I guess I will need to create a file name similar to this (with XXXX.root.log.tgz) and see if xrdadler32 is dumb or not.
--
Wei Yang | [log in to unmask] | 650-926-3338 (O)
On 9/29/19, 1:42 AM, "[log in to unmask] on behalf of Patrick McGuigan" <[log in to unmask] on behalf of [log in to unmask]> wrote:
Hi,
We are seeing an odd problem associated with performing checksums with xrdadler32.
I am copying files from one data server to another using client commands. As part of the copy process I verify the adler32 checksum of the file on the destination server. This is what is having problems.
The command that gets used works out to be:
xrdadler32 root://storage-10-6//xrd/atlasscratchdisk/rucio/user/bchargei/9c/d1/user.bchargei.data17_13TeV.physics_Main.DAOD_BPHY1.16_08_2019.v01.root.log.18890879.000052.log.tgz
and this fails with:
Error_accessing: root://storage-10-6//xrd/atlasscratchdisk/rucio/user/bchargei/9c/d1/user.bchargei.data17_13TeV.physics_Main.DAOD_BPHY1.16_08_2019.v01.root.log.18890879.000052.log.tgz
However this command succeeds:
xrdfs storage-10-6 query checksum /xrd/atlasscratchdisk/rucio/user/bchargei/9c/d1/user.bchargei.data17_13TeV.physics_Main.DAOD_BPHY1.16_08_2019.v01.root.log.18890879.000052.log.tgz
adler32 f4ac0c27 /xrd/atlasscratchdisk/rucio/...
I turned on XRD_LOGLEVEL=Dump and XRD_LOGFILE=xrootd-client-log
and ran both commands above. The log is attached to message.
Of note in the dump of the failed command:
The root URL is seemingly processed okay and the correct data server and path are identified
The xrdadler32 command successfully logs into the remote server and performs an kXR_stat call
The checksum is then seemingly retrieved via a kXR_query call.
WHen this is done, the dump seems to indicate that the xrdadler32 command is then trying to contact a second URL which is a portion of the original path:
[2019-09-28 18:09:49.150535 -0500][Dump ][Utility ] URL: log.18890879.000052.log.tgz
This of course fails, and the overall command seems to then fail.
This is not happening for all the files, but it is happening randomly for some files with longer path names.
I was using version 4.9.1 and was seeing this and updated to version 4.10 which fixed one path, but I am still seeing the behavior with 4.10.
Any ideas what is going wrong here?
Patrick
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1
