Bug 666383

Summary: Defining NO_NFS_ATIME_HACK breaks using mutt with encfs filesystems
Product: [Fedora] Fedora Reporter: Corinna Vinschen <vinschen>
Component: procmailAssignee: Jaroslav Škarvada <jskarvad>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 16CC: jskarvad, jurek.bajor
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Fixed In Version: procmail-3.22-29.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-24 19:58:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
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:

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
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):


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

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


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.

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:
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.