Closed Bug 66239 Opened 24 years ago Closed 17 years ago

Read Messages reappear as Unread messages.

Categories

(SeaMonkey :: MailNews: Message Display, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: skasinathan, Unassigned)

Details

Attachments

(2 files)

This is really a weird bug I'm seeing. Not reproducible always. 1. I have a folder named 'bugzilla', obviously filtered all the bugzilla notifications into this folder :) 2. I read all the messages in this folder today morning. 3. I had quit/restarted the app 4-5 times and everytime the app seems to be showing the messages in this folder as read. 4. When I launched the app again, all the msgs I read today morning as shown as unread. (and also shows the #of unread msgs in parenthesis near the folder name). Build and platform: Today's commercial build on Win NT.
QA Contact: esther → fenella
I have experienced similar problems--read messages not staying "read," and reverting back to unread later on. I've had this problem with in my messages in my Trash folder. I found that these messages had X-Mozilla-Status: 0000 Using a text editor, I changed the header to X-Mozilla-Status: 0001 The messages now stay "read." Besides the header, I don't know of any common characteristic tying the messages together. However, it seems like it may be happening to batches of messages that are downloaded together (i.e., not randomly to individual messages here and there.) I'm using Mac OS 9.1 2001012908.
Just an update: I saw this today too very frequently, but I'm using 2/1/01 commercial build on Win NT.
Bug 65746 describes similar problems.
I'm pretty sure this is something Laurel has a DUP of.
Suresh, is this imap or pop3?
David, I saw this in an imap account. Not sure about pop.
just fyi: I saw this couple of times using todays build. Once I restart the app everything seems to be fine.
QA Contact: fenella → laurel
yep, confirmed with build number 2001083103 - reading the newsgroups and they stay marked as unread. I was not expecting this bug.
I'm also seeing this periodically on a current build (2001100203) on Windows 2000 using IMAP. I haven't been able to figure out what triggers it.
I see this with 2002070913 and a Cyrus IMAP 2.0.16 server.
We use IMAP sever in conjunction with the Mail client and messages that are simply read in the bottom pane are marked as read as the user single-clicks each one to read the message in the bottom pane of the client. Then all of the suddenly, the several messages just read and auto-marked as read become marked as unread. I believe it is because the cached message view window is not being posted to the server before the client refreshes from the IMAP server when the timeout is up for checking for new messages. This only happens if you don't double-click the new message to bring it up in its own window.
I'm seeing this with 1.4RC1 on Windows and Linux both. It has gone from being random to being consistent. Every time I log in, all of the messages in some folders are re-marked as unread. It's consistent on which folders, but no clear reason why. It's almost funny. You open up messenger, and see the list of e-mails in your INBOX. They are all marked read. You enter your password to login, and suddenly they all get marked unread. 100% repeatable. Cyrus 2.2a Would an IMAP debug help?
yes, a log showing the following things (two logs, actually) log 1 - read a message in your INBOX, thus marking it read, then shutdown log 2 - open the INBOX you read in log 1. you say "some folders" and then INBOX, so I'm assuming the INBOX is one of these folders. thx, - David
You have the second log already. Since Mozilla clears the log at each startup, it would require two logs. Did you need the first, or is the one I submitted good enough? Yes, INBOX is one of the folders - and is the most annoying. Actually, as I test I'm beginning to think that it has gone to all folders. It's just that regardless of preferences, it doesn't actually check most folders until you open them up.
I need two logs since I need to see a log where you read a message, and then a second log where you open the very same folder with the very same message. Thx.
Attached file First log file -- open and read mail (deleted) —
This is still happening with 1.4rc3 and I've confirmed that it affects every folder. Here is the first logfile. I open my mail, enter my password, go to the folder "Keep" which has 4 messages. All appear unread. I select each one and read it. Then I exit Mozilla.
I open Mozilla again, open Mail, enter my password and then go to the folder "Keep". All messages there are unread. I believe you can also see that this happened in the Inbox as well, but I figured a small folder with 4 messages would be easier for you to read.
Joe, it looks like you have a problem on your IMAP server. When we select a folder, it's responding: -741527[28eea90]: 28ed5f0:mail.isite.net:A:CreateNewLineFromSocket: * OK (seen state failure) Unable to preserve \Seen state: System I/O error The server is coming back with a message saying that it's having some sort of problem keeping track of which messages are read. It's not coming back with this error in any kind of standard way, unfortunately, so there's really no way for us to propagate the msg back to the user. (putting an error message after the OK response is not a standard thing to do).
Okay, problem found and fixed. No to fix the real problem, what are you expecting? You tell me that this is non-standard, but you're not defining how this information should be conveyed. I'll create and submit a patch to Cyrus to deal with this, if you define what you are looking for.
there are several different ways in IMAP to tell the client that a folder is read-only: return READ-ONLY in the select instead of READ-WRITE don't return the "s" acl attribute indicating that we can't set the /SEEN flag don't return the /SEEN flag in the FLAGS or PERMANENT FLAGS But what you might want to do in this situation is return an ALERT to the user, since this is probably a pretty bad error that we need to tell the user about. None of those other things will actually cause us to tell the user anything since they're valid.
The folder was not read only, so your comments are unclear to me. Also, I am confused that you are receiving an error code, but not passing it on the user? I'm really not sure how you define this to be a server problem.
We're not receiving an error code - that's my point. We're receiving some random text after the OK in the OK response. That's not an error code.
And now we're back to my original point: Now to fix the real problem, what are you expecting? You tell me that this is non-standard, but you're not defining how this information should be conveyed. I'll create and submit a patch to Cyrus to deal with this, if you define what you are looking for. Last time I asked this, you wandered off on read-only. Now you again tell me the server did the wrong thing without telling me what the server should have done. Care to answer this?
Joe, the server is saying, in geeky English (not a language the imap parser deals with, just to be clear) that it can not maintain the /SEEN flag for the current folder. Hence, changes to the /SEEN flag will not be remembered. Here's what the server is saying: "OK (seen state failure) Unable to preserve \Seen state: System I/O error" What I'm suggesting is that instead of hiding this message in the text after the OK response (which imap clients are going to pretty much ignore anyway), the server generate an ALERT response to the same effect. This will cause the client to display a message to the user, who will then have to contact the server admin people. It won't "fix" the problem, or make the client suddenly do the right thing. The server is broken; it can't remember /SEEN state. There's nothing the client can do that will fix the server, or make it so that it does remember the /SEEN state. And presumably, there's nothing the server can do to fix itself, or it would have done it instead of just putting some text after an OK response.
I understand everything you're saying here. Thanks for the verbose reply, but I got all of that. I was just wondering how it should have dealt with it. I'll look through the code and see if I can pull together a patch. In the meantime, I'll get it filed as a bug.
Similar effects occur in the Linux version since at least 1.3 up till today (1.5 beta, build 2003090805). Upon opening Mozilla, if a new message gets filtered into one of my large folders, everything is OK, but if nothing new comes there, a group of ca 260 messages (the same ones every time) gets marked Unread. This effect is reproducible in my Local Folders. I use POP3 to retrieve the messages and delete them from the server.
i see this bug concurrently with bug 57660 and bug 171110, and i'm using pop3. a possible solution (described by david bienvenu in 171110) might be to try compacting all of your folders and see if this fixes things -- this adds the x-mozilla-status line to all messages in the folder.
Product: Browser → Seamonkey
Assignee: sspitzer → mail
is problem gone for you? Summary: Jo's problem was determined to be server - I don't know about the others.
Severity: normal → major
OS: Windows NT → All
Hardware: PC → All
Summary: Read Messages appears as Unread messages. → Read Messages reappear as Unread messages.
=> incomplete - no response if anyone still sees this please comment
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: