User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; MathPlayer 2.10b; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; InfoPath.2; .NET CLR 1.1.4322; .NET CLR 3.5.21022) Build Identifier: 3.0a3 Since moving up from TB 2 to Shredder 3 alpha, I keep getting error messages: Unable to open the summary file for _____. Perhaps there was an error on disk, or the full path is too long. where _______ is an IMAP folder. I've tried removing all the cached Imap files in my profile, but these intermittent errors keep cropping up. Reproducible: Sometimes Steps to Reproduce: 1. Open Shredder A3 2. After 15 min - 1 hour of using several IMAP accounts, clicking on some folders will begin to show this error. 3. Restart and the error goes away for a while...
deleted panacea.dat and localstore.rdf in profile. startup. ctrl+T to login to account, I get the same error. UI for this imap account shows only 4 folders, inbox and 3 folders I created via another PC since my last startup on this PC. i.e. my other 15 imap folders dont appear. console contains Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgFolder.getMsgDatabase]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://messenger/content/mailWidgets.xml :: parseFolder :: line 1942" data: no] and Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIINIParserFactory.createINIParser]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: file:///C:/Program%20Files/mozilla.org/TB%203.0b%20081128/components/nsUpdateService.js :: getLocale :: line 550" data: no] Source File: file:///C:/Program%20Files/mozilla.org/TB%203.0b%20081128/components/nsUpdateService.js Line: 550 I attempted to login 4-5 times across 2 restarts before I was able to log in to imap account. (including crash reported in Bug 467308) Now all folders appear. Before all this, was also fiddling with (deleting) some folders on imap server store in attempt to get rid of folders that shouldn't be appearing in TB UI. I don't have clear steps to reproduce. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081128 Shredder/3.0b1pre
I am seeing this too but on SeaMonkey (BuildID 20081130001326) It does not happen consistently but usually after I've deleted some emails and then tried to drag and drop another message from my inbox to another folder (which it fails on) and then I select another folder (sent for example) and get the popup error message. Seems to vanish equally inconsistently as well (even without restarting SM). See also bug 403902 I suspect this might be something in the imap backend rather than in the mail window.
I'm seeing this errror as well, Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 "Unable to open the summary file for <foldername>. Perhaps there was an error on disk, or the full path is too long." Restarting fixes this temporarily. Error console: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgFolder.getMsgDatabase]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://messenger/content/mailWidgets.xml :: parseFolder :: line 1942" data: no] I too saw this after a failed move/delete. Is there an open bug for failed deletes/moves?
As suggested by David Bienvenu, switching off "Message Synchronizing" on the affected account makes the popup error message not happen and there is no problem with moving/deleting emails. I have 1043 different folders on my IMAP account which may well be a factor.
I have about 600 folders, so this is probably contributing to the problem. Next time it comes up, I will try turning off the syncing and see if the problem goes away. I don't know if it is relevent, but I also notice that failures in searching within the folder occurs around this time as well (placing a search term in the search field reflows the message list, but nothing that I can tell is removed from the listing) - I'm still testing to see if one is truly dependent on the other or simply coincidental.
(In reply to comment #4) > switching off "Message Synchronizing" on the affected account makes the popup error message not happen and there is no problem with moving/deleting emails. FYI. Implementation plan of the feature is written in following page. > https://wiki.mozilla.org/MailNews:Better_Faster_IMAP_Plan
FYI. Current implementation looks to have been done by following bugs. > Bug 436615 - Better Faster IMAP: Preemptive/Automatic message download feature > Bug 435153 - Better Faster IMAP: Pseudo-offline Delete and Move support
I've checked in some fixes very recently so imap auto sync should not be keeping so many db's open
I'm still seeing this error with lastnights build and message sync enabled.
it turns out that we need to be more aggressive about closing the db's that auto sync opens...I'll work on that as soon as I can.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081230 Shredder/3.0b2pre
FYI. Bug 381771(INCOMPLETE) is a report for Tb 2 of absolutely same bug summary. As I wrote in Bug 381771 Comment #2, exception of Comment #3(first one in Comment #1) occurred on Tb 2 when path length for ".msf" really exceeded system limit.
Sounds like david has plans for this bug. Marking blocker.
bienvenu in comment #10 > it turns out that we need to be more aggressive about closing the db's that > auto sync opens...I'll work on that as soon as I can. bienvenu, is this completely addressed with some of the recent fixes (from the last 1-2 months)?
no, there's more work to be done in bug 470221, but I think that will resolve this one.
yeah, I forgot about bug 470221. good that it's blocking. bug 403902 reported against TB2 cites this message. So I'd like to clarify... Has problem this bug reports always existed and autosync only make the problem worse? (in which case 403902 may be a dupe) Or is this strictly speaking fallout of autosync and to be considered a regression? other remaining memory bugs bug 337837
FWIW, I haven't seen this bug in a while. I still have inbox synching on and lots and lots of folders. I believe I did reduce the total number of folders syncing however; should I turn those back up, or is that not relevant to the issue?
This is fallout from any code that opens all the databases and doesn't close them, on systems with a limited number of file handles. There have been other pieces of code that did this (since fixed), but autosync was the one people were most likely to run into.
i too am seeing this bug occur with eudora 8.0b6 on xp pro. all seems to be working fine. after moving some messages and/or creating new IMAP subfolders, the problem starts and is consistently present. i have both many IMAP and Local Folders; moving all te Local Folders such that Eudora cannot see them allows Eudora to work again. (i do have autosync on.) note that Thunderbird 18.104.22.168 is working fine with autosync enabled on all of the same files.
Thunderbird 2.0x doesn't have autosync. It sounds like this may not be a big issue anymore in beta 3, but I'd like to leave it open for investigation...
I used process explorer after leaving TB up overnight and there weren't any unexpectedly open .msf files. This was with gloda and autosync on, but vista search integration off. I've turned Vista search integration back on, and I'm seeing quite a few more .msf files staying open than I would expect. I'll have a quick look at that code and see if it's releasing folder cached db's or not...
Created attachment 393198 [details] [diff] [review] fix os search integration case this makes things much happier in my tests... usually we check things like whether this was an inbox or trash and leave the db cached in that case, but I'd like to try moving away from that so I've left out the checks. It would be really nice to have a test case like gloda does for making sure that the search stuff doesn't bloat the open db/.msf files.
pinging for review...
Created attachment 394928 [details] [diff] [review] patch I'll checkin... I decided to check if it's the inbox before closing the db, just to be on the safe side. This is what I'll check in.
this should be fixed now.
Tested with nightly: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:22.214.171.124pre) Gecko/20090818 Shredder/3.0b4pre ID:20090818054203 It seems that the problem has been eased, but still exists. Here are my error logs; Error: uncaught exception: [Exception... "Component returned failure code: 0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) [nsIMsgFolder.updateFolder]" nsresult: "0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)" location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Thunderbird%203.0%20Beta%204/modules/dbViewWrapper.js :: FolderNotificationHelper_notifyOnLoad :: line 129" data: no] Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIMsgFolder.msgDatabase]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://messenger/content/mailWidgets.xml :: parseFolder :: line 1968" data: no]
It seems that the problem has completely gone with Thunderbird 3 Beta 4.
Verified per comment 29