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:
I assume the problem is also applicable to RHEL4
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
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
What's the output of this command? gconftool-2 --get /apps/evolution/mail/accounts
[werner@wgold ~]$ gconftool-2 --get /apps/evolution/mail/accounts [<?xml version="1.0"?> <account name="wgold" uid="1110316154.5825.16.redhat.com" enabled="true"><identity><name>Werner Gold</name><addr-spec>wgold</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.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> ]
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
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.
Hello Dave, any solution here, because I'd like to have a reliable mail program ... Werner
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!
Is this problem still present in Fedora Core 6 or later?
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.
Closing as INSUFFICIENT_DATA.