[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: movemail fails to get lock



Joe Pfeiffer <pfeiffer@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.


Reply to: