Status

MailNews Core
Database
--
critical
RESOLVED INVALID
15 years ago
8 years ago

People

(Reporter: maciej zawadzki, Assigned: Bienvenu)

Tracking

({dataloss})

Trunk
x86
Windows XP
dataloss

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
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
(Reporter)

Comment 1

15 years ago
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.
(Assignee)

Comment 2

15 years ago
-> Navin
Assignee: bienvenu → naving
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

15 years ago
QA Contact: gayatri → esther

Comment 3

15 years ago
I think we will have to obtain exclusive write lock when writing to Inbox. 
(Assignee)

Comment 4

15 years ago
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

15 years ago
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.
(Assignee)

Comment 6

15 years ago
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

15 years ago
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.
(Assignee)

Comment 8

15 years ago
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?
mass re-assign.
Assignee: naving → sspitzer

Comment 10

14 years ago
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
Product: MailNews → Core

Comment 11

12 years ago
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.
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody

Comment 13

10 years ago
Frank wrote WFM on 1/2007 "NO, not had this recently. Running version 1.5.0.9 (20061206)"
QA Contact: esther → database

Comment 14

10 years ago
David, comment 7 and 8 still valid?  (the conversation never completed)
Assignee: nobody → bienvenu
Product: Core → MailNews Core
(Assignee)

Comment 15

9 years ago
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

8 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Keywords: dataloss
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.