Print

Print


Hi Patrick,

I initially thought this maybe a bug in xrdadler32 handling file name. It is not - I created a file in my storage and xrdadler32 can get its checksum:
root://atlrdr1//xrootd/atlas/atlasscratchdisk/rucio/user/bchargei/9c/d1/user.bchargei.data17_13TeV.physics_Main.DAOD_BPHY1.16_08_2019.v01.root.log.18890879.000052.log.tgz

So what version of xrdadler32 are you using? What OS and xrootd server release are you running in storage-10-6?

regards,
--
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