Description of problem:
For a discussion of this problem see:
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
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
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):
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.
st_atime == st_mtime
st_atime < st_mtime
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
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.
procmail-3.22-29.fc16 has been submitted as an update for Fedora 16.
* 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:
then log in and leave karma (feedback).
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.