On Fri, Aug 03, 2018 at 07:57:48AM +0200, Vincent Lefevre wrote: > On 2018-07-26 18:39:30 -0700, Kevin J. McCarthy wrote: > > My question is about the merit of performing the lstat double-check. > > Does mutt need to be doing this? Does this work around some strange bug > > with certain filesystems or NFS? > > sshfs has bugs by default. When I use it, I need the -o workaround=rename > option, otherwise some operations fail (I don't remember what exactly). > Has this been tried here, with Mutt?
The reporter in #61 said "I disabled hardlinks for my filesystem and
that fixes the problem". Not sure if that's the same thing you tried.
I think if the link() returns 0, it's safe for the code to assume all
went well. So, the fix I plan to make is remove the compare_stat call
afterwards, but keep the stat calls for now:
lib.c:
@@ -517,12 +517,21 @@ int safe_rename (const char *src, const char *target)
* did already exist.
*/
+#if 0
+ /*
+ * Remove this check, because it causes problems with maildir on
+ * filesystems that don't properly support hard links, such as
+ * sshfs. The filesystem creates the link, but the resulting file
+ * is given a different inode number by the sshfs layer. This results in an
+ * infinite loop of created files.
+ */
if (compare_stat (&ssb, &tsb) == -1)
{
dprint (1, (debugfile, "safe_rename: stat blocks for %s and %s diverge;
pretending EEXIST.\n", src, target));
errno = EEXIST;
return -1;
}
+#endif
/*
* Unlink the original link. Should we really ignore the return
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
