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 <[email protected]> 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.
pgpFmctgMFQlP.pgp
Description: PGP signature
