|Summary:||Defining NO_NFS_ATIME_HACK breaks using mutt with encfs filesystems|
|Product:||[Fedora] Fedora||Reporter:||Corinna Vinschen <vinschen>|
|Component:||procmail||Assignee:||Jaroslav Škarvada <jskarvad>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||procmail-3.22-29.fc16||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-01-24 19:58:43 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Corinna Vinschen 2010-12-30 12:45:42 UTC
Description of problem: For a discussion of this problem see: http://lists.fedoraproject.org/pipermail/users/2010-December/389644.html The Fedora version of procmail defines the NO_NFS_ATIME_HACK macro in procmail-3.22-rhconfig.patch. This explicitely disables the code which makes sure that st_atime < st_mtime. This in turn breaks mutt's recognition of mailboxes with new mails under some circumstances. In my case, I keep the more confidential mails in MBOX mailboxes inside of an encfs encrypted directory. The underlying filesystem is an ext4 filesystem runing with default mount options. This includes the "relatime" option. When procmail appends mails to unencrypted MBOXes on this ext4 filesystem, then st_mtime is always > st_atime and mutt's "new mail" recognition works as expected. However, when procmail appends mails to MBOXes inside the encfs encrypted directory, the file's st_atime is == st_mtime afterwards. So the result is that mutt never reports new mails in my encfs encrypted MBOXes. Re-enabling the code in mailfold.c which handles the NFS atime hack fixes this problem. I'm also pretty sure this is not only a problem with encfs. NFS comes to mind... Version-Release number of selected component (if applicable): procmail-3.22-25 How reproducible: Steps to Reproduce: 1. Create encfs encrypted directory and mount it 2. Create a procmail rule which writes to a MBOX file within the aforementioned encrypted directory 3. Write yourself a mail which triggers the procmail rule 4. Observe how st_atime and st_mtime correlate (stat(1)). 5. Rebuild procmail without `#define NO_NFS_ATIME_HACK' 6. Send another mail 7. Observe how st_atime is now < st_mtime. Actual results: st_atime == st_mtime Expected results: st_atime < st_mtime
Comment 1 Corinna Vinschen 2012-01-15 14:27:02 UTC
Ping? Is there a reason why there was never a followup to this bug report? The problem is still present in Fedora 16. I just didn't notice it anymore because I was using a locally patched procmail all the time. The patch to #define NO_NFS_ATIME_HACK in procmail-3.22-rhconfig.patch should really go away to enable correct st_atime handling on EncFS or NFS. Corinna
Comment 2 Jaroslav Škarvada 2012-01-16 12:57:30 UTC
It seems like bug/feature of encfs - I filled bug 782068. The proposed change makes sense to me and seems to be harmless in other cases - accepted.
Comment 3 Fedora Update System 2012-01-16 13:15:08 UTC
procmail-3.22-29.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/procmail-3.22-29.fc16
Comment 4 Fedora Update System 2012-01-16 21:26:58 UTC
Package procmail-3.22-29.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing procmail-3.22-29.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0613/procmail-3.22-29.fc16 then log in and leave karma (feedback).
Comment 5 Fedora Update System 2012-01-24 19:58:43 UTC
procmail-3.22-29.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.