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
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.
I think we will have to obtain exclusive write lock when writing to Inbox.
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?
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.
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.
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.
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?
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
I have just experienced this kind of msf corruption (and fix by removing the .msf file) with T-Bird 22.214.171.124 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.
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Frank wrote WFM on 1/2007 "NO, not had this recently. Running version 126.96.36.199 (20061206)"
David, comment 7 and 8 still valid? (the conversation never completed)
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.
(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.