On Tuesday, 02 January 2007 at 18:23, Thomas Roessler wrote: > I suspect that this is indeed related. Actually, a similar problem > exists for the vfat file system. > > What happens for vfat is this: In order to create a file safely, > mutt creates a temporary directory that it believes it controls [is > that assumption really valid for vfat?], and creates the file in > there. Mutt then needs to move the file one level up. > > It appears that, in doing so, we have successfully reduced one > impossible problem (safely creating a file) to another one (safely > moving/renaming a file): To move a file safely, we have for ages > used link(2) and unlink(2), since rename(2) is unsafe on NFS. > Unfortunately, link(2) will fail on file systems that don't support > hard links. > > Now, the mutt code even tries to be clever about this, by detecting > EXDEV and falling back to rename(2) in that case -- according to a > comment in safe_rename(), we once made an assumption that file > systems that react with EXDEV to a link(2) that we believe is > guaranteed to be within a single file system can be trusted to do a > proper rename(2), presumably based on the assumption that we're > actually dealing with Coda. > > Just to make it all a bit funnier, vfat seems to return EPERM when > you try to invoke link(2), which is not a condition that we seem to > be able to usefully evaluate or react to. I have been toying with the idea of falling back to 'rename' if the error is anything but EEXIST (or whatever error we'd expect from NFS when the rename should fail). But short of that, the patch I proposed a couple of days ago explicitly recognises the VFAT and SSHFS link errors (which are thankfully not EEXIST) and falls back to rename for them. It's not clear to me that this is a safety problem unless we have reason to believe rename is broken on other filesystems than NFS, and that those same filesystems _also_ can't handle link (in which case it seems the filesystem is simply a very bad choice for tempfiles).
Attachment:
pgp74yPyBr2XE.pgp
Description: PGP signature