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, view it on GitHub, or unsubscribe.

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