Closed Bug 381771 Opened 17 years ago Closed 16 years ago

Unable to open the summary file _____. Perhaps there was an error on disk or the full path is

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: yoyo811, Assigned: mscott)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: 2.0.0.0

After leaving Thunderbird running for several hours, the message will pop up in a dialog box, and Thunderbird will have to be restarted in order for it to check mail.

Unable to open the summary file _____. Perhaps there was an error on disk or the full path is too long

Reproducible: Always

Steps to Reproduce:
1. Start Thunderbird
2. Wait several hours
3. Click a file to view messages
Actual Results:  
Thunderbird produces the above error message, and will not be able to display messages/check for new mail.

Expected Results:  
Absence of such an error.

1 GB RAM, Windows XP, 2.4 GHz P4. Default theme.
(In reply to comment #0)
> Unable to open the summary file _____.
(Q1) What is exact message and file name? Please get screen shot and attach to
     this bug, if file name itself is important and if hard to write down.
(Q2) What is real file path for the mail folder?
     "Copy folder location" of folder thru context menu, paste to notepad.exe.
     And check directory/file structure for the path.

If folder file is "X:\...\Any_String" and path length is maximum, creation of "X:\...\Any_String.msf" probably fails. Tb can't handle this case well?
Correction of previous comment.
When Tb 2.0.0.0(MS Win-XP SP2) and folder creation thru UI, maximum length is applied to "X:\...\Any_String.msf".
When folder of Any_StringX (longer 1), Tb did nothing even if "X:\...\Any_StringX" is shorter than maximum path length, and folder was created when folder name is Any_String then "X:\...\Any_String/Any_String.msf" were successufully created.

If "X:\...\Any_StringXX", "X:\...\Any_StringXXX"  "X:\...\Any_StringXXXX" etc. exists(for example, by manual copy), Tb displayed folder name of "X:\...\Any_StringXX" and so on, but when clicked the folder, following error displayed in Error Console.
> Error: uncaught exception: [Exception... "Component returned failure code: 0x80550006 [nsIMsgFolder.getMsgDatabase]"  nsresult: "0x80550006 (<unknown>)"  location: "JS frame :: chrome://messenger/content/mailWidgets.xml :: parseFolder :: line 2061"  data: no]
Needless to say, "X:\...\Any_StringXX.msf" can not be created because of path length limit.
I too receive this error several times a day.  Once it's started to appear, I can't access any further mailboxes until I restart Thunderbird.  However, what I can add to the bug report is that sometimes a folder is accessible, and other times it's not.  That is, I might click on an IMAP account's inbox or top level folder (eg Library), and be told that it's: "Unable to open the summary file for Library.  Perhaps there was an error on disk, or the full path is too long.", yet if I restart Thunderbird I would be able to get to this folder.

In this case, the folder location is imap://username@mail.myorganisation.uk/Library, and on disk, it's C:\Documents and Settings\ME\Application Data\Thunderbird\Profiles\vfw4b28w.default\ImapMail\mail.**********.uk\Library.msf

This is in Thunderbird 2.0.0.4 (20070604) on Windows XP SP2.

Entirely reproducible on my computer:  Just clicking on lots of imap folders one after another will cause this error to occur.  Maybe it's running out of file handles or something like that?
We have three Windows XP SP2 machines with Thunderbird 2.0.0.6 doing the same thing.  Restarting TB fixes the problem temporarily.

All users access a large number of IMAP folders.
When windows, default profile location consumes long path length. 
> C:\Documents and Settings\<login_name>\Application Data\Thunderbird\Profiles\<random><prof_name>\Mail\ImapMail\...

Workaround:
(A) Move profile location from default one to other place such as C:\Tb-Profs
(B) Move mail directory location to other place such as C:\Mail
Note: When (B), change of "Local Directory" setting in "Server Settings" requires restart of Thunderbird. (long-lived Bug 2654)
We still have the problem, even with the above workarounds.  We can view all of the folders after TB is started, but we get this error after some time - usually after accessing a number of folders.  After clicking on the Account Name (the parent for the folder tree) we can access *all* folders again until it breaks again.
(In reply to comment #6)
> We still have the problem, even with the above workarounds.

To Rob Fraser:
Was/is your problem really a problem which occurs when path length exceeds path length limit of local file?

No, I am not convinced it is a path length problem.  I have counted up the characters and although some of the paths are long, it is not always the longest path names that cause the error.  And not all of our users/workstations have the issue even though they are using a shared account via IMAP4 - so they are accessing the same length path names.

Let me clear up a few points:

1) It doesn't always happen.  Sometimes I can access a folder, and other times I can't.  This suggests that it's nothing to do with path length.  So, I don't see how WADA's suggestion (A) on 22nd August will resolve this.

2) Once the error has happened on a folder, there are only two ways I've found to regain access:

i) Restart thunderbird

or

ii) Choose to work offline, then navigate away from the folder.  Then stop working offline, and return to the folder.  Thunderbird then downloads all the headers for the folder, and you can then access the folder.

Because of 2ii, I wonder if a file somewhere is actually getting corrupt?  I'm more than happy to do some monitoring with ethereal or sysinternals filemon or similar, if someone can tell me what to look for.  

I've now moved to a different computer (Windows 2003 Server, TB 2.0.0.6), and have the same problem.  I didn't copy any profiles - I just set it up from scratch.  I've got four IMAP accounts, all on the same server, some of which have hundreds of folders.
We are still experiencing this problem with the existing users and it has recently started affecting more users.  A Windows Vista PC has also been installed on this site and it is now experiencing the same issue.
To Rob Fraser & Rob S ('me too' posters):

Are you sure that original problem in comment #0 by bug opener is same problem as yours?
Please note that even "IMAP or POP3" is still unclear when comment #0 case and no response from bug opener.
Please note that workaround of my comment #5 is for and only for problem due to path length limit.

Your case sounds IMAP connection loss related issue, and "close(fold) of IMAP account then open(expand) again" seems to be a recovery procedure.
Get IMAP protocol log and check real protocol level flow first.
(See Bug 402793 Comment #1 for getting protocol log).
And search bugzilla.mozilla.org well for already opened/fixed/dup'ed bugs, via "Advanced Search". 
If new problem and Tb's fault, open separate bug, with attaching protocol log.

Closing as INCOMPLETE, because no response from bug opener for 10 months.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
Yes, comment #0 is the same problem.  We are getting more and more users experiencing this issue.  We only use IMAP.  I think the error message is spurious - there is no identifiable path length problem and this issue is caused by something else. 

The "close(fold) of IMAP account then open(expand) again" is not a good workaround as it doesn't work for all users and is still a hassle for the users when it does work.

No sign of any similar bug with an advanced search.

I will get IMAP protocol log and check real protocol level flow.  I'll then open a new bug as you suggest.
follow up is bug 540214 for those who still see a problem with version 3
You need to log in before you can comment on or make changes to this bug.