 |
 |
> I suppose it's also possible that something is messed up in the server and the file name is associated with the wrong data That's the very strange part of all of this. The DPM site never saw a request for the "correct" filename. That is, the client tried to open `81CB9803-B71C-464B-AD3F-5B53605EF41E.root` and recorded that in the client log. Around the same time (within a 5 second skew), DPM site logged an access for `B04C9BFD-09C6-0D4D-8E67-2D4DDCE88027.root`. The "correct" filename `81CB9803-B71C-464B-AD3F-5B53605EF41E.root` never existed at the DPM site and the client never logged anything about `81CB9803-B71C-464B-AD3F-5B53605EF41E.root`. So for DPM to be the culprit, it would have to advertise the availability of a file it never had and, for an incoming client, record the wrong filename in the log but send the client to the contents of the wrong filename. Theoretically, this can't be the fault of the DPM site, the redirector, or the client -- and yet it seems to happen multiple times a day! > Simple to test, open the file at the server and see if you get the right file. When done by hand, trying to open `81CB9803-B71C-464B-AD3F-5B53605EF41E.root` (which shouldn't exist at the DPM site) results in a file-not-found and opening `B04C9BFD-09C6-0D4D-8E67-2D4DDCE88027.root` results in the correct file contents. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/1097#issuecomment-561761833 ######################################################################## 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