Bug 666383 - Defining NO_NFS_ATIME_HACK breaks using mutt with encfs filesystems
Summary: Defining NO_NFS_ATIME_HACK breaks using mutt with encfs filesystems
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: procmail
Version: 16
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jaroslav Škarvada
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-12-30 12:45 UTC by Corinna Vinschen
Modified: 2012-01-24 19:58 UTC (History)
2 users (show)

Fixed In Version: procmail-3.22-29.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-24 19:58:43 UTC
Type: ---


Attachments (Terms of Use)

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.


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