Description of problem: procmail on EL5 uses fcntl locking, however the alpine package from EPEL uses flock locking. This can lead to mail loss if the mailbox is opened simultaneously by both. This is a repeat of an old bug that Red Hat developed a patch for (#15779). Perhaps this patch should be included in the EPEL release.
OK... I do not use alpine for reading local mail (only IMAP), can you provide a test case? My understanding was that alpine was doing a flock emulation that really uses fcntl on Linux. I love things like #15779, "mail programs will use fcntl() for locks" but no actual patch there. I miraculously found the Red Hat 7 pine SRPM here... http://stuff.mit.edu/afs/dev/system/rhlinux/redhat-7.0-updates/SRPMS/ It includes the patch but does not apply it! * Thu Oct 4 2001 Mike A. Harris <mharris> 4.40-0.1 - Updated to pine-4.40 - Disabled pine-4.04-noflock.patch, pine-4.31-openssl.patch to see if it is still needed
Created attachment 311628 [details] pine flock-over-fcntl emulation
Created attachment 311629 [details] pine flock-over-fcntl emulation source file
alpine does not do flock-over-fcntl-emulation, but it should. That is the issue. The disabled pine-4.04-noflock.patch you found is not the patch to fix this issue. The relevant patch is the one labeled imap-4.7c2-flock.patch, and the flock.c source file. I will attach both to this message. This seems to patch alpine cleanly, so they probably should be included in the alpine RPMs.
I'll take a look when I get the chance, but again I have no way to reproduce the problem. Also, Fedora policy is to get this patch accepted upstream if possible, so please report to that list as well.
Where did this code come from and what is the license? If nalin at Red Hat is really the author as the RCS line implies I guess we will probably have to get him and/or Red Hat to assign copyright to UW and release under ASL2 along with alpine. If it's code floating around the net (as with a lot of the old pine patches) I'm not sure it could be vetted at all.
MRC pretty clearly rejects the fcntl locking since it causes problems on NFS: http://mailman1.u.washington.edu/pipermail/alpine-info/2008-July/000996.html A followup indicates you can get procmail to use mlock (.lock files) by appending a : to rules, do you know if this can be the default?
Procmail does use .lock files in addition to fcntl, but alpine will still balk the next time it tries to perform an operation on a mailbox that has been changed since the last time it checked even if a .lock file was in place during the change. The problem also crops up when software other than procmail is involved. For example, try using Red Hat's mutt (which uses fcntl only) and alpine at the same time on the same folder and see what happens. Concerns about fcntl locking may be valid. It might be a bad idea. But nevertheless Red Hat uses fcntl. My concern when I opened this bug report is that this EPEL package is not compatible with RHEL because it does not use the same locking scheme as RHEL. As for the source of the patch, it was included in the Pine SRPMS when Red Hat still included it in their distributions. It can still be found in some Red Had and Mandrake archives by googling for pine flock .
If alpine is not noticing the proper use of .lock files, it sounds like an alpine bug. Could you report this to the alpine mailing list? I know the patch was distributed with older Red Hat pine RPMs, but EPEL and Fedora have a fundamentally different policy to stay away from patches that will not be accepted upstream. EPEL alpine will only have what alpine developers will add, and that may not include fcntl locking (just as they will not add maildir support). A workaround would be to run a local IMAP server such as dovecot and access your mail with alpine via IMAP.
> policy to stay away from patches that will not be accepted upstream. Keep in mind that is only a guideline/recommendation. There happen to be cases where it is in fedora's interest to disagree with upstreams and carry "unapproved" patches. Note, this comment does not reflect on this particular case, and I personally don't have any strong opinion one way or the other. One reason being that I have yet to see any evidence of or any test case to show anything beyond only theoretical problems or dataloss. If such a case *could* be made, I would venture that upstream (and us here in fedora) would be much more likely take the issue much more seriously and find ways to address it.
Stephen, I'm afraid I'm going to have to close this as CANTFIX, due to the detailed technical reasons in the alpine developer response here: http://mailman2.u.washington.edu/pipermail/alpine-info/2008-July/000996.html Again I recommend the workaround of running a local IMAP server such as dovecot to access your mail with alpine. Thanks for reporting the issue, Joshua Volunteer Fedora Package Maintainer
In case it is helpful to anybody else, the above link seems to have moved to: https://mailman13.u.washington.edu/pipermail/alpine-info/2008-July/000996.html And the following gives a redirect to the above: https://mailman.u.washington.edu/pipermail/alpine-info/2008-July/000996.html