 |
 |
I believe I understand this problem. Our TPC client uses a fixed chunk size to make the read requests. It would seem that the dCache and also the native xrootd servers are smart enough to understand that if you are at the end of the file and the chunk size exceeds the file size, it sends back only the remaining bytes with kXR_ok. However, the RAL server seems to be much more of a literalist. It will send kXR_oksofar, and then try to fill out the difference between the remaining bytes in the file and the requested number of bytes (the chunk) by sending back a packet of that size ... either 0's or garbage, I don't know. The TPC client is waiting for the kXR_ok, gets the excess bytes and writes them to the file. Then ka-pluey, file size error.
The fix is easy on my part: always ask for the exact remainder, not the standard chunk size, on the final read request.
I will fix and test, and post a bug fix ASAP.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
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