178842 - Mail messages corrupted

Status: RESOLVED INVALID

(MailNews Core :: Database, defect)

Description

[maciej zawadzki]

I'm running Mozilla 1.1 and sometimes the email messages that I receive get
corrupted.  I mean that the message bodies do not correspond to the titles and
the message boundaries are out of whack as well.  For example, the body of one
message start with the middle of the text actually sent by the sender, and may
continue into the middle of the next message.  

This first started happening when I turned on the option to automatically
download messages from the server.  I have Norton antivirus which scans every
incomming message.  When Norton finds an infected message it pops up a dialog
box and waits for user input.  I believe that this is causing the problem on my
system.  After leaving my computer on during the night, I will typically find it
with the Norton dialog box in the morning.  I will click the quarantine button
one the dialog and the dialog disappears allowing me to view the email messages
received over night.  But that is when all messages after the infected message
are infected.  I typically get out of Mozilla mail and the browser (including
memory resident portion) and do a restart and then new messages are no longer
corrupted.  

I read over the existing bugs and found that bug 140112 may be related to this.
 After reading bug 140112 I did not think that this was necessarily a duplicate
so I entered this new bug report.

Thanks,
--Maciej

Comment 1

[maciej zawadzki]

I appears that deleting the .msf file of the floder that holds the corrupted
message restores the message.  This is good news.  It is not the message store
that is corrupted, just the display of the message.

Comment 2

[David :Bienvenu]

-> Navin

Comment 3

[Navin Gupta]

I think we will have to obtain exclusive write lock when writing to Inbox. 

Comment 4

[David :Bienvenu]

could you explain a little more what you think is going on? Is some other piece
of mozilla code coming along and corrupting the mailbox when this happens? Or
does somehow the popping up of the dialog by Norton somehow causing us problems? 

Comment 5

[Navin Gupta]

I think Norton may be writing to Inbox at the same time. It could be removing
infected message that causes all the file offsets to go wrong! So exclusive
write lock would prevent other apps from writing to Inbox when we are
downloading messages.

Comment 6

[David :Bienvenu]

So, I think you're saying we should open the file in exclusive write mode, so
that no other app can write to it - I agree with that. However, I'm not sure how
we do that - maybe if we pass in PR_WRONLY to the "new nsIOFileStream" call, it
would open the file in exclusive write mode for the OS.

Comment 7

[Navin Gupta]

I looked into opening file in exclusive write mode. Passing PR_WRONLY to
nsIOFileStream would not do it because that is interpreted as just write
privilige. There is one more flag that tells how to deal w/ subsequent opens.
nspr always allows subsequent opens to have both read/write priviliges. This is
for win32

FILE_SHARE_READ|FILE_SHARE_WRITE

207     file = CreateFile(name,
208                       access,
209                       FILE_SHARE_READ|FILE_SHARE_WRITE,
210                       NULL,
211                       flags,
212                       flag6,
213                       NULL);

More info about shared mode from msdn.microsoft.com

dwShareMode
    [in] Share mode for object. If dwShareMode is 0, the object cannot be
shared. Subsequent open operations on the object will fail, until the handle is
closed.

    This parameter can be set to one or more values. The following table shows
the possible values for dwShareMode.
    Value Description
    FILE_SHARE_READ Indicates that subsequent open operations on the object will
succeed only if read access is requested.
    FILE_SHARE_WRITE Indicates that subsequent open operations on the object
will succeed only if write access is requested.

Comment 8

[David :Bienvenu]

so to be clear, you're suggesting changing nspr? Or adding a flag to NSPR that
will cause it to open the file with shareMode 0? Or is there some way of getting
NSPR to do this right now?

Comment 9

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 10

[Frank Johnson]

I have also experienced this corruption. Nothing else is trying to write to the
mail file and it happens with to msg's with very small attachments like an html
copy of the text. Running Linux version 1.6, previous versions, I think before
1.4 did not do this.  Frank

Comment 11

[Shai Berger]

I have just experienced this kind of msf corruption (and fix by removing the .msf file) with T-Bird 1.5.0.2 on Win2K.

This (maybe) caused data loss, because I sometimes rely on message headers when deleting messages, so I don't know how many messages I mis-deleted before noticing something was wrong.

Comment 12

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 13

[Wayne Mery (:wsmwk)]

Frank wrote WFM on 1/2007 "NO, not had this recently. Running version 1.5.0.9 (20061206)"

Comment 14

[Wayne Mery (:wsmwk)]

David, comment 7 and 8 still valid?  (the conversation never completed)

Comment 15

[David :Bienvenu]

My understanding was that comment 7 was describing a capability in Windows that is not accessible through NSPR, and we use NSPR to open files.
I don't think we use nsIOFileStream at all anymore, but the issue may still be present.

Comment 16

[Wayne Mery (:wsmwk)]

(In reply to comment #15)
> My understanding was that comment 7 was describing a capability in Windows that
> is not accessible through NSPR, and we use NSPR to open files.
> I don't think we use nsIOFileStream at all anymore, but the issue may still be
> present.

So it sounds like we can close this. If anyone disagrees, please reopen.