Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
I did not try against the Vanderbilt endpoint because I do not have any token to access it nor a directory I can use...
I identified a bug in the code which is easily fixable: The four bytes sequence 76 26 ac e0 is the adler32 checksum of the file I compute the checksum against via curl... Though, the output is base64 encoded while it should not be --> I found the code to fix.
By default, if a user passes a checksum type that is unknown by XRootD, XRootD will use the one that is configured here: https://xrootd.slac.stanford.edu/doc/dev55/xrd_config.htm#_Toc88513998
In my case, I configured xrootd.chksum adler32.
In the case the user asks for sha, sha-256, the server returns the base64 encoding of the adler32 checksum of the file (like shown above).
@abh3 or @bbockelm shall we change the behaviour ? (I believe the answer is yes... :D)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
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