I am running mutt 0.95.{5,6}i on SunOS 4.1.4. It appears that
fchdir() often fails [*], and so the current directory is not
restored after it's changed by dotlock_invoke() in dotlock.c.
This causes nonsensical error messages when doing something
like "mutt -f ../../maildirectory/mailbox" (that is, when the
path is specified relatively): mutt tells me "No such file or
directory". The lockfile is left behind, so if I repeat the
command, mutt first tells me that it's reading the file, then
asks whether to remove the lockfile, before reporting "No such
file ...".
(*--For what it's worth, the man page says, "fchdir() is
provided as a performance enhancement and is guaranteed to fail
under certain conditions.")
--
Paul Kimoto <[EMAIL PROTECTED]>
