Red Hat Bugzilla – Bug 206376
mbox folder corruption
Last modified: 2011-02-08 09:53:39 EST
Description of problem:
Deletion of the top message in an mbox folder can cause corruption.
Version-Release number of selected component (if applicable):
Always with this folder and some others.
Steps to Reproduce:
1. Copy the attached folder to a mail spool or folder path
2. Delete the top message
The first 6 characters (From .) are removed from the From line of
the following message.
Only the deleted message should be removed, not part of the next message.
This works fine with the same dovecot version on 32 bit RHEL4. It only
fails with 64 bit.
This looks like a clone of 178683 and 162781 but those are both closed
so I'm starting a new entry. The additional information is that it
fails on 64 bit only and the attachment which demonstrates the problem.
Got similar results with another folder. This has a large message at the top
with a number of attachments. The end of the message looks like this:
If that top message is deleted the start of the folder looks like this:
This is different from the other one. Instead of deleting part of the
following From line it leaves part of the last line and the blank line
from the deleted message.
Deleting that message from the same folder on 32 bit RHEL produces no
Found another troublesome folder. This one does cause problems on 32 bit
but not in the same way. On 64 bit any time the top message is deleted
the folder becomes corrupted. On 32 bit it's only every second deletion!
I think I've found a solution: remove the X-UID headers and the problem
disappears for all the problem folders I've identified so far.
Apologies for the frequent posts but I was desperate to get this problem resolved.
Anyway I think I've solved it (for us at least). I discovered that the problem
only occurs if the index files are in an NFS mounted directory. (The default
puts them in the user's home directories which are NFS mounted in our case).
Configuring an index directory local to the mail server seems to have solved it:
default_mail_env = whatever:INDEX=/var/cache/dovecot/indexes/%u
Don't worry and thanks for the info. I don't think there will be anything like
an easy fix, but the workaround looks fairly good to me.
1)there is mentioned attachment for testing this bug, where this can be found?
2)there is mentioned this bug is related to NFS mounts, I don't know if NFS was changed recently, but is it possible to reproduce this right now? With new mbox?
The problem we had was fixed when I moved the index files out of the user's NFS mounted home directories onto local storage on the mail server. The relevant setting in dovecot.conf is:
default_mail_env = mbox:~/mail/:INBOX=/var/mail/%u:INDEX=/var/cache/dovecot/indexes/%u
You need to create the directory /var/cache/dovecot/indexes on the mail server:
mkdir -p /var/cache/dovecot/indexes
chmod 1777 /var/cache/dovecot/indexes
It's only the INDEX files that need to be on local storage. NFS mounted mail folders (in ~/mail) haven't caused any problems.
ok, to be clear (correct me if I'm wrong):
- you use workaround for index files so you don't know if this problem still exists
- you don't have mbox used for reproducer anymore
(In reply to comment #9)
> - you use workaround for index files so you don't know if this problem still
correct. Having the index files on local store is also more efficient so it makes sense to configure it that way.
> - you don't have mbox used for reproducer anymore
It's almost 3 years since we resolved this problem so no I don't have the test mbox files. All the problem mbox folders had been migrated from UW imap but that's based on very limited testing.
ok, I'll try to reproduce it myself. thanks for the info
since workaround is known, lowering severity to high
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
I'm sorry for not addressing the issue in RHEL-4. As dovecot
was not scheduled for update in RHEL-4.9, I'm closing that bugzilla WONTFIX. If
you are still experiencing the issue with RHEL-5 or RHEL-6, feel free to reopen it against RHEL-5 or RHEL-6 respectively.