The default bug view has changed. See this FAQ.

"Unable to open the summary file for _______. Perhaps there was an error on disk, or the full path is too long." search integration leaving dbs open

VERIFIED FIXED in Thunderbird 3.0b4

Status

MailNews Core
Backend
--
major
VERIFIED FIXED
9 years ago
8 years ago

People

(Reporter: Chris Rodgers, Assigned: Bienvenu)

Tracking

({regression})

Trunk
Thunderbird 3.0b4
x86
Windows Vista
regression
Bug Flags:
blocking-thunderbird3 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

9 years ago
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk

Comment 2

8 years ago
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.

Comment 3

8 years ago
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?

Comment 4

8 years ago
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.

Comment 5

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

Comment 8

8 years ago
I've checked in some fixes very recently so imap auto sync should not be keeping so many db's open

Comment 9

8 years ago
I'm still seeing this error with lastnights build and message sync enabled.
(Assignee)

Comment 10

8 years ago
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.
something related to dbs?

I have local folder that receives filtered imap mail and in the past few days it won't display message body unless I go offline and return to online. If I reply the compose body has only "On .... wrote:"

There's a lot in the console and of course they are not timestamped.  But perhaps this message goes with this problem

Error: [Exception... "'JavaScript component does not have a method named: "handleEvent"' when calling method: [nsIDOMEventListener::handleEvent]"  nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  location: "<unknown>"  data: no]
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081230 Shredder/3.0b2pre

Updated

8 years ago
Flags: blocking-thunderbird3?

Updated

8 years ago
Component: Mail Window Front End → Backend
Keywords: regression
Product: Thunderbird → MailNews Core
QA Contact: front-end → backend
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.
Assignee: nobody → bienvenu
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0rc1
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)?
(Assignee)

Comment 16

8 years ago
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
Depends on: 470221

Comment 18

8 years ago
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?
(Assignee)

Comment 19

8 years ago
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.

Comment 20

8 years ago
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 2.0.0.22 is working fine with autosync enabled on all of the same files.
(Assignee)

Comment 21

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

Comment 22

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

Comment 23

8 years ago
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.
Attachment #393198 - Flags: review?(sid.bugzilla)
(Assignee)

Updated

8 years ago
Status: NEW → ASSIGNED
Whiteboard: [has patch for review]
(Assignee)

Updated

8 years ago
Duplicate of this bug: 494223
(Assignee)

Comment 25

8 years ago
pinging for review...
Attachment #393198 - Flags: review?(sid.bugzilla) → review+
Whiteboard: [has patch for review]
(Assignee)

Comment 26

8 years ago
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.
Attachment #393198 - Attachment is obsolete: true
(Assignee)

Comment 27

8 years ago
this should be fixed now.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Comment 28

8 years ago
Tested with nightly:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.3pre) 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]
Summary: Unable to open the summary file for _______. Perhaps there was an error on disk, or the full path is too long. → "Unable to open the summary file for _______. Perhaps there was an error on disk, or the full path is too long." search integration leaving dbs open
Target Milestone: Thunderbird 3.0rc1 → Thunderbird 3.0b4

Comment 29

8 years ago
It seems that the problem has completely gone with Thunderbird 3 Beta 4.
Verified per comment 29
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.