 |
 |
Hi Andy,
Thanks a lot for looking at this: This hasn't been reported as causing a problem in any production use; it was only something that caused me to make a separate investigation during a test. So I'm not sure it is worth pursuing this given there's some discussion around it: I think it's perfectly fine if you'd like to either leave it as is, or change it in anyway you'd prefer. (If you wanted a certain behaviour you could also let me know, and I'll try to prepare an appropriate patch, if you like). For instance if the conclusion is that delayed destroy is only that, not a kind of retry, we could avoid ever adding files which fail their initial close to the delayed list but directly to the lost list, or exit the attempted close+delete early from XrdPosixFile::DelayedDestroy() (before the ddMaxTries attempts) if a close is attempted but fails. Or, If indeed this a balance of doing the least bad thing in the face of a potentially inconsistent state we just leave it as is, since apparently it is not causing real problems.
Yours,
David
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
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