Bug 150603 - Email loss with mbox mailstorage
Email loss with mbox mailstorage
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Matthew Barnes
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-08 16:27 EST by Werner Gold
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-02 12:51:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Werner Gold 2005-03-08 16:27:10 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050224 Firefox/1.0.1 Fedora/1.0.1-1.3.1

Description of problem:
My mail gets fetched with fetchmail and is delivered locally through postfix into a local mbox file. When postfix delivers mails locally while evolution is open, some of the downloaded mails never appear in the file and therefore get lost. I switched off all filtering. It looks like a locking problem.


Version-Release number of selected component (if applicable):
evolution-2.0.4

How reproducible:
Sometimes

Steps to Reproduce:
1. Deliver mail with postfix to a mbox file while evolution is accessing it.
2.
3.
  

Actual Results:  Loss of Emails

Additional info:
Comment 1 Werner Gold 2005-03-08 16:28:23 EST
I assume the problem is also applicable to RHEL4
Comment 2 Dave Malcolm 2005-03-11 00:11:09 EST
What's the output of this command?
gconftool-2 --get /apps/evolution/mail/accounts

What filesystem is the mbox file on?

Evolution has rather different locking strategies for the different types of
local file.  I've checked through the code; looks like the "spool" URL should
work, it's configured to use fcntl( , F_SETLK, ) on the whole file as
appropriate.  However, it appears that the "mbox" URL is not doing any advisory
locking.  This is still the case in the latest Evolution 2.2
Comment 3 Werner Gold 2005-03-11 02:59:53 EST
Hello,

User: werner
/dev/hda5 on /home type ext3 (rw)
[root@wgold ~]# postconf | grep INBOX
home_mailbox = mail/INBOX


Evolution uses: /home/werner/mail/ as local mailspool.
It is the only way, that gives me access to the INBOX and to other Mailfolders
within a single account configuration. 

[root@wgold ~]# postconf | grep lock
default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what]
blocked using $rbl_domain${rbl_reason?; $rbl_reason}
deliver_lock_attempts = 20
deliver_lock_delay = 1s
mailbox_delivery_lock = fcntl, dotlock
stale_lock_time = 500s
virtual_mailbox_lock = fcntl
Comment 4 Dave Malcolm 2005-03-11 13:03:49 EST
What's the output of this command?
gconftool-2 --get /apps/evolution/mail/accounts
Comment 5 Werner Gold 2005-03-11 13:27:38 EST
[werner@wgold ~]$ gconftool-2 --get /apps/evolution/mail/accounts
[<?xml version="1.0"?>
<account name="wgold@redhat.com"
uid="1110316154.5825.16@wgold.stuttgart.redhat.com"
enabled="true"><identity><name>Werner
Gold</name><addr-spec>wgold@redhat.com</addr-spec><reply-to></reply-to><organization></organization><signature
uid=""/></identity><source save-passwd="false" keep-on-server="false"
auto-check="true"
auto-check-timeout="1"><url>spool:/home/werner/mail/;xstatus</url></source><transport
save-passwd="false"><url>smtp://wgold@pobox.stuttgart.redhat.com</url></transport><drafts-folder>email://local@local/Drafts</drafts-folder><sent-folder>email://local@local/Sent</sent-folder><auto-cc
always="false"><recipients></recipients></auto-cc><auto-bcc
always="false"><recipients></recipients></auto-bcc><pgp encrypt-to-self="false"
always-trust="false" always-sign="false"
no-imip-sign="false"><key-id></key-id></pgp><smime sign-default="false"
encrypt-default="false"
encrypt-to-self="false"><sign-key-id></sign-key-id><encrypt-key-id></encrypt-key-id></smime></account>
]
Comment 6 Dave Malcolm 2005-03-15 23:24:18 EST
The configuration in comment #5 is using the spool backend; this should be using
fcntl( , F_SETLK, ) on the file as appopriate.  flock-locking support is
disabled at configuration time when we build Evolution.

The dot-locking support in Evolution may not be getting set up properly.  As an
experiment, does it fix the bug if you do this:?
chgrp mail /usr/libexec/evolution/2.0/camel/camel-lock-helper
chmod g+s /usr/libexec/evolution/2.0/camel/camel-lock-helper


Comment 7 Werner Gold 2005-03-16 02:41:48 EST
I clicked around in the INBOX folder and also deleted one message while
fetchmail was running. 25 out of 120 mails went to nowhere. Evolution complained
that index and folder are out of sync even after resync attempts.
Mail retrievals after the deletion of one mail led to error messages that the
entry points to the wrong index number.
I had to close and reopen evolution to get rid of the error messages, but the 25
mails are gone. The whole handling of mbox files looks _very_ broken to me.
Comment 8 Werner Gold 2005-03-22 08:39:48 EST
Hello Dave,

any solution here, because I'd like to have a reliable mail program ...

Werner
Comment 10 Matthew Miller 2006-07-10 17:58:47 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 11 Matthew Barnes 2007-01-02 07:14:19 EST
Is this problem still present in Fedora Core 6 or later?
Comment 12 Matěj Cepl 2007-08-31 11:21:17 EDT
The distribution against which this bug was reported is no longer supported,
could you please reproduce this with the updated version of the currently
supported distribution (Fedora Core 6, or Fedora 7, or Rawhide)? If this issue
turns out to still be reproducible, please let us know in this bug report.  If
after a month's time we have not heard back from you, we will have to close this
bug as INSUFFICIENT_DATA.

Setting status to NEEDINFO, and awaiting information from the reporter.

Thanks in advance.
Comment 13 Matthew Barnes 2007-10-02 12:51:25 EDT
Closing as INSUFFICIENT_DATA.

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