This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 206376 - mbox folder corruption
mbox folder corruption
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: dovecot (Show other bugs)
4.0
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Michal Hlavinka
qe-baseos-daemons
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-13 19:14 EDT by Ian Mortimer
Modified: 2011-02-08 09:53 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-02-08 09:53:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ian Mortimer 2006-09-13 19:14:02 EDT
Description of problem:
Deletion of the top message in an mbox folder can cause corruption.


Version-Release number of selected component (if applicable):
dovecot-0.99.11-4.EL4

How reproducible:
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
3. 
  
Actual results:
The first 6 characters (From .) are removed from the From line of
the following message.


Expected results:
Only the deleted message should be removed, not part of the next message.


Additional info:
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.
Comment 1 Ian Mortimer 2006-09-13 20:30:52 EDT
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:

------_=_NextPart_001_01C6D52E.38C067FD--

From ...

If that top message is deleted the start of the folder looks like this:

.38C067FD--

From ...

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
corruption.
Comment 2 Ian Mortimer 2006-09-17 20:49:04 EDT
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!
Comment 3 Ian Mortimer 2006-09-17 21:45:53 EDT
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.
Comment 4 Ian Mortimer 2006-09-18 21:56:10 EDT
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
Comment 5 Petr Rockai 2006-09-22 04:20:02 EDT
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.
Comment 7 Michal Hlavinka 2009-07-17 04:27:28 EDT
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?

thanks
Comment 8 Ian Mortimer 2009-08-05 17:58:59 EDT
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.


--
Ian
Comment 9 Michal Hlavinka 2009-08-06 10:05:30 EDT
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
Comment 10 Ian Mortimer 2009-08-06 18:08:30 EDT
(In reply to comment #9)

> - you use workaround for index files so you don't know if this problem still
> exists

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.

--
Ian
Comment 11 Michal Hlavinka 2009-08-07 13:52:26 EDT
ok, I'll try to reproduce it myself. thanks for the info

since workaround is known, lowering severity to high
Comment 18 RHEL Product and Program Management 2010-10-22 14:53:26 EDT
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.
Comment 19 Michal Hlavinka 2011-02-08 09:53:39 EST
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.

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