Joe Pfeiffer <pfeif...@cs.nmsu.edu> writes: > After some upgrades, when I try to use VM to read my mail from within > emacs, movemail has been unable to get my mail. I've added some > switches to it to try to get a better picture of what it's doing; > currently I've got > '(vm-movemail-program-switches '("-vvv" "--debug-level=99" > "--debug-line-info")) > > When I try to fetch my mail with these switches, I get the messages > > movemail: mboxrd.c:89: > mboxrd_mailbox_init_stream:mu_mapfile_stream_create > (/home/joseph/INBOX.crash): No such file or directory > movemail: mboxrd.c:96: > mboxrd_mailbox_init_stream:mu_file_stream_create > (/home/joseph/INBOX.crash): Success > movemail: mailbox `/home/joseph/INBOX.crash': cannot lock: Lock file > check failed > > movemail exited with code 1 > > in the *output of movemail /var/mail/joseph /home/joseph/INBOX.crash* buffer. > > Does anyone have any idea what could be wrong here? Much googling has > not given me any ideas...
Something I didn't realize was relevant when I posted: my home directory is encrypted with encfs. I'm pretty sure at this point my issue is a race condition in encs. I rebuilt mailutils (which includes movemail) from source so I could run it under gdb. It turns out the way they do file locking is to create a file with a nearly-random name, create hard link to it with the requested file name, and then do a stat on both to see if their parameters match (I don't immediately see the advantage over just creating the lock file with O_EXCL, but it's not my code). The two stats are not matching. When I step through using gdb, it works. So, I'll be filing a bug report against encfs when I get a chance. In the meantime, using movemail to move the mail to a file on a non-encrypted filesystem, and then mv'ing it to INBOX.crash, works.