Print

Print


This is a timing issue. When the rename happens, the xrootd sends the cmsd a message that old file no longer exists and then a second message that the new (i.e. renamed) file does exist and completes the client interaction. If it so happens that the next rename occurs before the cmsd can register the new file as existing, it will indicate that the file does not exist. Short of making this a transnational operation relative to the cmsd, this timing hole will exist. This exposure exists if the renamed file was looked up by the cmsd at some point in the past (e.g. a stat() operation on the target file) was done on the recent past. I do not propose we add that kind of capability to the cmsd as this kind of operation is rarely, if ever, done in practice.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub



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