On Wed, Aug 22, 2018 at 10:04:12AM -0500, Derek Martin wrote: > I actually think that the MH folder code is at fault here, not the > stat() call in safe_rename(), despite potential issues with the latter. > If safe_rename() fails with EEXIST, what logic suggests retrying > forever is a good idea?
Thank you Derek. I first thought about changing the mh.c code, but the code is actually incrementing a counter and regenerating time() as part of the filename for each retry (take a quick look at _maildir_commit_message()). I didn't want to put an arbitrary limit, because Murphy's Law says eventually someone would hit it, and logically there is no need. Steffen's cautions apply to dotlock code, which is a different case and is not affected by this change. I'm inclined to keep the commit unless a regression appears or someone can show proof the change is unsafe. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
