Gitlab ticket #61 reported an infinite loop (creating files) when using maildir over sshfs. The merits of doing this are a separate discussion - what I'm interested in is the behavior of safe_rename().
In this case, link(2) reports success. But to be extra careful, safe_rename() performs a lstat() on the source and dest file and compares the results. If the stats don't match, safe_rename() sets errno=EEXIST, saying essentially to the caller the dest file already existed. The maildir/mh code, has a "forever" loop that increments a counter in the dest filename and keeps trying upon EEXIST until the safe_rename() succeeds. (see _maildir_commit_message() for an example). Now, the problem is that sshfs is cheating, and is not actually creating a hard link. Hence the lstat double-check fails, and mutt loops creating files "forever". 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? Would another possibility be to skip the lstat double check, or to fail without setting EEXIST if the lstat check doesn't match? Thanks for any advice on this. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
