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

Derek Martin invalid at pizzashack.org
Wed Aug 22 15:04:12 UTC 2018


On Tue, Aug 21, 2018 at 03:37:23PM -0700, Kevin J. McCarthy wrote:
> On Wed, Aug 22, 2018 at 07:13:21AM +1000, Cameron Simpson wrote:
> > On 21Aug2018 07:07, Kevin J. McCarthy <kevin at 8t8.us> wrote:
> > > On Tue, Aug 21, 2018 at 11:30:03AM +0200, Vincent Lefevre wrote:
> > > > But as I understand it, this means that the link got created, but the
> > > > system thinks that it wasn't, and link() returns a non-zero value.
> > > > 
> > > > So, I also think that if link() returns 0, then all went well.
> > > 
> > > That was my reading too.  :-)
> > 
> > For what it's worth, that is my reading too.
> 
> Thanks Cameron and everyone.  I've just pushed the patch up to master.

I just saw all the new activity in this thread, and I got to thinking
about this some more.  I think both of the reasons mentioned here have
legitimacy. Though as I previously pointed out if you stat() after the
link() and don't get a match (on a local file system), it's possible
that this is because in between the two calls, someone else replaced
the file (it's somewhat unlikely, but this is the nature of race
conditions).  But I don't think there's a better way to effect the
desired outcome, since there's no atomic way to do a link() and also
stat() on the new link.

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?  I can think of no reasons, but I can think of
one that says it is not: The user is unlikely to be in the process of
removing/renaming the file that Mutt is trying to rename, and probably
has no reason to imagine a need to do so, so the infinite loop seems
inevitable if safe_rename() fails.

Of course if the previous version of safe_rename() is retained, the
sshfs users may get an error when one has not actually occured, but
sshfs is a hack, so you get what you get...

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-dev/attachments/20180822/7f0cfb18/attachment.asc>


More information about the Mutt-dev mailing list