 |
 |
Well, based on the actual log it would seem to be a problem in gfal. In xroot protocol there is no such thing as reporting final size. Tyhe client is on the hook to add up all the pieces. Given there was no stat() after the final write. It would strongly point to a bug in gfal. But, by all means, follow up other possibilities. On Thu, 5 Aug 2021, Albert Rossi wrote: > ``` > ***@***.*** ~]$ xrdcp5x --tpc delegate only xroot://ceph-gw8.gridpp.rl.ac.uk:1094/dteam:test1/domatest/jwalder/HTTP_1GB xroot://fndcatemp2.fnal.gov:1095//pnfs/fs/usr/test/arossi/volatile/HTTP_1GB > [956MB/953.7MB][100%][==================================================][6.639MB/s] > Run: [ERROR] Server responded with an error: [3019] File size mismatch (expected=1000000000, actual=1002438656) (destination) > ``` > > GFAL has nothing to do with it, but something on the RAL end I think is sending a bad final dsize. I need to double check this, but I'm wondering if the xrdcp client does something special to make sure the size is legit, which our embedded TPC client also needs to do. That's my current thought. > > -- > You are receiving this because you were mentioned. > Reply to this email directly or view it on GitHub: > https://github.com/xrootd/xrootd/issues/1454#issuecomment-893605594 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/1454#issuecomment-893624732 ######################################################################## 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