Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 455104 - incompatible locking between MDA and alpine
Summary: incompatible locking between MDA and alpine
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: alpine
Version: el5
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Joshua Daniel Franklin
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-11 23:04 UTC by strovato
Modified: 2008-09-11 21:17 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-09-11 21:17:37 UTC


Attachments (Terms of Use)
pine flock-over-fcntl emulation (deleted)
2008-07-12 00:00 UTC, strovato
no flags Details | Diff
pine flock-over-fcntl emulation source file (deleted)
2008-07-12 00:01 UTC, strovato
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 15779 None None None Never

Description strovato 2008-07-11 23:04:02 UTC
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.

Comment 1 Joshua Daniel Franklin 2008-07-11 23:31:08 UTC
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@redhat.com> 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


Comment 2 strovato 2008-07-12 00:00:34 UTC
Created attachment 311628 [details]
pine flock-over-fcntl emulation

Comment 3 strovato 2008-07-12 00:01:04 UTC
Created attachment 311629 [details]
pine flock-over-fcntl emulation source file

Comment 4 strovato 2008-07-12 00:01:18 UTC
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.

Comment 5 Joshua Daniel Franklin 2008-07-12 00:39:40 UTC
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.

Comment 6 Joshua Daniel Franklin 2008-07-15 06:57:30 UTC
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.

Comment 7 Joshua Daniel Franklin 2008-07-16 21:45:51 UTC
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?

Comment 8 strovato 2008-07-23 17:37:59 UTC
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 .

Comment 9 Joshua Daniel Franklin 2008-07-25 15:58:21 UTC
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.

Comment 10 Rex Dieter 2008-07-25 16:10:42 UTC
> 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.

Comment 11 Joshua Daniel Franklin 2008-09-11 21:17:37 UTC
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


Note You need to log in before you can comment on or make changes to this bug.