Closed Bug 470834 Opened 13 years ago Closed 12 years ago
Some msf files appear to be ignored repeatedly even after a compact
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:188.8.131.52) Gecko/2008120122 Firefox/3.0.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20081222 Shredder/3.0b2pre I installed the latest build from last night, tagged: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20081222 Shredder/3.0b2pre I have roughly 50 Local Folders that get populated via POP3 mostly, with a few message moved by hand from an IMAP account as well. In TB2, all of the folders behave exactly as I expect. In TB3.0b1, one of the folders would repeatedly behave as if there was no ".msf" file available. Often (not every time) that I would visit the folder, it would rebuild the index (there are 7879 messages in the folder). There are 717MB in the file. When I installed Shredder today, it would rebuild that index file nearly every time I visited that folder. Then, when I visited another folder that is sometimes problematic, it showed the list of emails correctly, but couldn't view any one of them in the Preview Pane. Worse, double-clicking on any mail would bring up a blank window, so it wasn't just a Preview Pane problem. Compacting the folder didn't help. Deleting the msf file and then coming back to the folder didn't seem to help, and I thought that Shredder was hanging. I quit and restarted, and the msf file appeared, and the folder was working again. A few minutes later, I tried to move a message from my Inbox to that folder. Nothing happened. I went to visit the folder and Shredder complained that another function was still in progress and that I couldn't view the folder until it was done. I waited a bit and then quit. I started up TB3.0b1 and still saw the message in the Inbox. I moved it again and then visited the other folder. I had two copies of the moved file, so the first one succeeded, even though it locked the folder and wouldn't show it to me (probably would have after a quit and restart). For now, I've reverted to TB3.01b, since it appears to be a little more stable for me. Reproducible: Sometimes Steps to Reproduce: 1. Visit one of many folders that is large with many messages in it 2. Progress bar appears showing that the folder is being processed 3. Eventually, the folder contents appear Actual Results: Nothing specific, it feels like it's related to some kind of msf file problem, but I have no idea. Expected Results: Folder contents display correctly, and individual messages can be viewed in the Preview Pane and also in a standalone window if the message is double-clicked.
Next phenomenon is also reported in Bug 469448. Rebuild index(which seems to be due to corrupted .msf or deleted .msf) occurs on many mail folders, just after upgrade to Tb 3(beta or trunk) from tb2. Something incompatible exists in ".msf" content? Or 3.0b2pre misinterprets ".msf" content which created by himself? Or a kind of garbage(created by former Tb) causes rebuild index by 3.0b2pre and the garbage is still kept after rebuild index? (Initial "rebuild index" was almost same as "delete of .msf". But "rebuild index" was changed to keep some data in old msf file, in order to keep data such as tag of mail in IMAP folder which is kept in local ".msf" only.) (Q1) When problem occurs with 3.0b2pre, will "delete of .msf file" resolve problem? > I tried to move a message from my Inbox to that folder. Nothing happened. How did you move? Via move menu? Or Drag&Drop? I saw similar phenomenon when move mail via menu after manual rebuild index. But it was bypassed when I did mail move by Drag&Drop. (Q2) When problem occurs with 3.0b2pre, can "mail move by Drag&Drop" be a workaround?
hadar, please retest with beta 2 or recent nightly and update bug. also see questions for you in comment 2. xref bug 479285 and its friends
Severity: normal → major
Sorry for the delay in responding to comment #2. I did indeed move the mails via drag & drop, and that didn't work. Once I realized that I might actually be able to "lose mail", I reverted to TB2. I realize that my data folders were secure, but of course, at best, deleted mails would show up if the msf file was deleted. Anyway, I considered upgrading to Beta 2 when I saw the announcement, but reconsidered for a different reason (that I don't think I ever reported). I have one email that comes in nightly that is over 100K of plain text. Having that formatted and ready to read in TB2 takes 2-5 seconds. It took 30-60 seconds for the wait cursor to go away in TB3. Not the biggest deal in the world, but annoying nonetheless. Anyway, I'll give Beta 2 a try (since you asked), but it will likely be tomorrow before I have a chance to install and test. I'll report back here either way. Thanks!
I just installed TB3b2 a few minutes ago. So far, so good, but obviously, not enough time to be sure. I was able to compact a few folders, move an email or two, etc. Of course, I was able to do that in TB3b1 as well, until I couldn't, so I'll report back if I have a problem, now that I'll be using this beta full time. I know this doesn't belong in this issue, so I apologize, but the "Display Images" button still behaves incorrectly (it's been reported so many times, that I've given up caring, which is why I'm not "officially" reporting it again...)...
ok to close?
Version: unspecified → Trunk
From my perspective, now using TB3b2 for two weeks, I think it's fixed, and this bug can be closed. That said, amazing timing that I thought I tripped the bug not 10 minutes ago. Here are the steps that made it "appear" to return, but I was able to move the message on the next attempt, which wasn't true the last time. I had 10 unread messages in a folder with 945 messages in it. When I finished reading one, I clicked and dragged it into another folder. Normally, I do it in one smooth motion, and it works perfectly. This time, I accidentally dragged the message _down_ first, over the other 9 unread messages. I never let go of the mouse button, so after sliding it down, I dragged it over the target folder. It wouldn't "release". That's the same behavior I saw before. But, once I released the mouse, with the message still in the original folder, I was able to drag it to the target folder, and it worked correctly...
(In reply to comment #7) > From my perspective, now using TB3b2 for two weeks, I think it's fixed, and > this bug can be closed. WFM per comment #7 (reporter). Feel free to reopen it if I'm wrong.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.