Bug 666383

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