Closed Bug 100781 Opened 23 years ago Closed 22 years ago

Unread messages changed to read when compacting folder

Categories

(MailNews Core :: Backend, defect, P2)

x86
All
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: paulo.vilela, Assigned: Bienvenu)

References

Details

(Keywords: dataloss, Whiteboard: [ADT3 rtm])

Attachments

(1 file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20010913
BuildID:    2001091303

Trying to campact a local folder I get the message : "Do you wish to compact all
local and offline folders because the total wasted space in all accounts exceeds
the purge threshhold ?" 

I press OK, I get the message "Compacting folder xxx" 

After it finishes, i chack the Inbox folder. My Unread messages in Inbox are
changed  into Read messages.

The Inbox folder had been selected as a "for offline reading" folder.

Whenthis happened I working online


Reproducible: Always
Steps to Reproduce:
Checkk description

Actual Results:  check description

Expected Results:  Just compact the seleted folder
-> Navin
Assignee: bienvenu → naving
Component: Mail Database → Mail Back End
QA Contact: esther → sheelar
This is happening only for online folders configured for offline use as well.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
ok this code marks the message as read. cc bienvenu on how to fix 
this problem.

nsMsgHdr::MarkRead(nsMsgHdr * const 0x063ea380, int 1) line 239
nsMsgFolder::MarkMessagesRead(nsMsgFolder * const 0x0415dd0c, nsISupportsArray * 
0x063ef8c0, int 1) line 2139 + 27 bytes
nsImapMailFolder::MarkMessagesRead(nsImapMailFolder * const 0x0415dd0c, 
nsISupportsArray * 0x063ef8c0, int 1) line 1535 + 18 bytes
nsImapUrl::SetMsgLoadingFromCache(nsImapUrl * const 0x063ea1f0, int 1) line 1261
nsImapMockChannel::ReadFromLocalCache() line 7187
nsImapMockChannel::AsyncOpen(nsImapMockChannel * const 0x063ea030, 
nsIStreamListener * 0x03d2b95c, nsISupports * 0x063ea1f4) line 7218 + 8 bytes
nsImapService::FetchMessage(nsImapService * const 0x046d4c10, nsIImapUrl * 
0x063ea1f0, int 268435490, nsIMsgFolder * 0x0415dd0c, nsIImapMessageSink * 
0x0415ddd0, nsIMsgWindow * 0x00000000, nsIURI * * 0x00000000, nsISupports * 
0x03d2b958, const char * 0x063e9e10, int 1) line 1238 + 59 bytes
nsImapService::CopyMessage(nsImapService * const 0x046d4c14, const char * 
0x06365c40, nsIStreamListener * 0x03d2b95c, int 0, nsIUrlListener * 0x00000000, 
nsIMsgWindow * 0x00000000, nsIURI * * 0x00000000) line 924 + 79 bytes
nsOfflineStoreCompactState::OnStopRequest(nsOfflineStoreCompactState * const 
0x03d2b95c, nsIRequest * 0x063654a0, nsISupports * 0x063655b4, unsigned int 0) 
line 593 + 74 bytes
nsImapCacheStreamListener::OnStopRequest(nsImapCacheStreamListener * const 
0x06363d30, nsIRequest * 0x06363be4, nsISupports * 0x063655b4, unsigned int 0) 
line 6809 + 43 bytes
nsOnStopRequestEvent::HandleEvent() line 162
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x063b00a4) line 65
PL_HandleEvent(PLEvent * 0x063b00a4) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x009d28b0) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x08cf0b84, unsigned int 49404, unsigned int 0, 
long 10299568) line 1071 + 9 bytes
USER32! 77e71820()
009d28b0()
hmm, I'm not sure. The code is there to make sure that when you read a message
that happens to be in the local cache, it gets marked read on the server.
However, that code also gets run when you copy the message, and when we compact
an offline store, we do it by copying the non-deleted messages. So the trick is
to make sure that the copy code doesn't cause the message to get read, while
still making it so that reading a message from the offline store marks the
message read. Taking.
Assignee: naving → bienvenu
Status: ASSIGNED → NEW
Keywords: nsbeta1
Priority: -- → P2
Target Milestone: --- → mozilla0.9.7
Keywords: nsbeta1nsbeta1+
Target Milestone: mozilla0.9.7 → mozilla0.9.9
Priority: P2 → P1
Status: NEW → ASSIGNED
Priority: P1 → P2
Target Milestone: mozilla0.9.9 → mozilla1.0
Discussed in 2/25 bug mtg w Mktng, PjM and Engineering.  Decision was to move to
1.2 and nsbeta minus this bug.
Blocks: 122274
Keywords: nsbeta1+nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2
renominating - this is dataloss - we shouldn't be marking unread messages as
read. I'm not sure this was fully appreciated by the adt.
Keywords: nsbeta1-dataloss, nsbeta1
I see this on Linux as well - BuildID 2002032603, RedHat Linux 7.2. This happens
not only to Inbox but to other folders with unread messages that are marked for
offline. The IMAP server I use is Cyrus IMAP.
Keywords: mozilla1.1
OS: Windows 98 → All
Discussed at Mail News bug meeting.  Decided to make ADT3 and plus this bug.
No longer blocks: 122274
Keywords: nsbeta1nsbeta1+
Whiteboard: [ADT3]
Target Milestone: mozilla1.2alpha → mozilla1.0
Attached patch proposed fixSplinter Review
check the url action to make sure we're fetching the msg (i.e., displaying it)
before marking it read. Thus, we won't mark it read while copying the message.
Navin, can I get a review? thx.
Comment on attachment 79332 [details] [diff] [review]
proposed fix

r=naving,

In this method SetMsgLoadingFromCache
we have declared rv twice, Can you remove
it before checking in.
Comment on attachment 79332 [details] [diff] [review]
proposed fix

r=naving,

In this method SetMsgLoadingFromCache
we have declared rv twice, Can you remove
it before checking in.
Attachment #79332 - Flags: review+
Comment on attachment 79332 [details] [diff] [review]
proposed fix

sr=sspitzer

it might be best to explicitly return NS_OK instead of rv, as the code above
may change one day.
Attachment #79332 - Flags: superreview+
fix checked into trunk.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 137303 has been marked as a duplicate of this bug. ***
*** Bug 124513 has been marked as a duplicate of this bug. ***
Change qa contact
QA Contact: sheelar → gchan
*** Bug 143542 has been marked as a duplicate of this bug. ***
Keywords: adt1.0.0
Whiteboard: [ADT3] → [ADT3 rtm]
Using commercial trunk builds:
2002-05-21-08-trunk/ nt 4.0
2002-05-21-07-trunk linux 2.2
2002-05-21-03-trunk/ mac 9.2.2
2002-05-21-08-trunk/ mac 10.1.4

Verified when you compact a imap folder via auto compaction, results
in new mesgs still being 'new' and not marked as read.
Tried both inbox and subfolders. Folders marked for offline and folders
not marked for offline.



Marking verified on trunk. 
When fix lands on branch, I'll go back and verify the branch.
Status: RESOLVED → VERIFIED
adt1.0.1+ (on ADT's behalf) for checkin to the 1.0 branch, pending Driver's
approval.
please checkin to the 1.0.1 branch ASAP. once there, remove the mozilla1.0.1+
keyword and add the fixed1.0.1 keyword.
Attachment #79332 - Flags: approval+
fixed on 1.01 branch
using commercial branch on NT 4.0, linux 2.2, mac 9.2.2, mac 10.1.4:
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020607 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607
Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.0.0) Gecko/20020610
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.0) Gecko/20020610

Verified when you compact folder via autocompaction, for folders
marked for offline use, that new mesgs still stay new.

Verified on branch.

adding kw: verified1.0.1 & replacing it over fixed1.0.1
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: