safe_rename() and verifying the result of link(2)

[Kevin J. McCarthy]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-dev/attachments/20180822/497cc415/attachment.asc>