Open Bug 249807 Opened 17 years ago Updated 2 years ago
Folder pane does not display a sub-folder if the total length of the folder branch exceed 128 char (No error message when path
_length for local file for mail folder=".msf" exceeds MS Win's path length limit=256 chars)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040704 Firefox/0.9.0+ Build Identifier: version 0.7+ (20040704) Thunderbird doesn't show subfolders if the total folderpath length exceeds 128chars. On local accounts you aren't allowed to exceed the limit - if you do, it just don't close the "create folder" window. On imap accounts it continues, but if the exceed the limit, then they aren't shown. Reproducible: Always Steps to Reproduce: 1. Create a folder "some stupid very long name" 2. Continue #1, but as subfolder of last created folder Actual Results: you'll only reach 4th level or such, when you aren't allowed to create another subfolder(local) or they just don't show up(imap) Expected Results: it should show the folders
Please, i need this bug quickly close, I have big problem with that. We have a lot of subfolders in our company ... thks, Alain
everybody need a quick fix - make more parent folders to put all your sub-folders in...
still exist in TB 20041113 BRANCH
Severity: normal → major
Component: Mail Window Front End → General
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
After some thought, this might be a Windows(XP) issue with paths max length at 256. Well, it's still reproduceable, but what should be done? Error/warning message perhaps?
suite Bug 283446 confirmed. I assume the same is true of thunderbird, but I didn't test. hansen, how do you come up with 128 characters?
Severity: major → normal
I submitted this bug for another person from the forums. Now I've tested again with Thunderbird version 3 alpha 1 (20060528) which fixes this bug. There isn't any hold at 128 chars - it continues up to 256 chars, which is max for Windows XP. It might go higher on unix-like systems. And there's a popup-message, when hitting the OS limit, but sometimes I get an error instead: Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIXULTreeBuilder.getIndexOfResource]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: EnsureFolderIndex :: line 1593" data: no] Source File: chrome://messenger/content/msgMail3PaneWindow.js Line: 1593 The strange thing is; now when the popup-message doesn't show and I get the error in the console, then the folder is actually created on the server (FreeBSD 5.3, Courier-IMAP 4.0.1), but not on the client (WinXP). I'm not sure if I should close this bug and open a new one on the error...?
Summary: Folderpane does not display a sub-folder if the total length of the folder branch exceed 128 char → Folderpane does not display a sub-folder if the total length of the folder branch exceed 128 char (No error message when path_length for local file for mail folder=".msf" exceeds MS Win's path length limit=256 chars) file" for
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Folderpane does not display a sub-folder if the total length of the folder branch exceed 128 char (No error message when path_length for local file for mail folder=".msf" exceeds MS Win's path length limit=256 chars) file" for → Folder pane does not display a sub-folder if the total length of the folder branch exceed 128 char (No error message when path_length for local file for mail folder=".msf" exceeds MS Win's path length limit=256 chars)
If non-ascii folder name is used at IMAP server, path length of local mail folder file exceeds system limit at "smaller folder depth/shorter mail folder name" than user's expectation, because non-ascii folder name is passed in modified UTF-7 and the string of modified UTF-7 is used as local mail folder file name. - Folder name : N chars (in unicode) == N*2 bytes in UTF-16 - modified UTF-7 : roughly (N*2)*(4/3) asci chars(bytes) (modified UTF-7 is similar to base64 encoding)
Similar situation can occur on local mail folder(POP3 or "Local Folders"), if mail folder file is manually copied. > Copied mail folder file : C:\<mail_directory>\...sbd\...\...sbd\file_name > Path length of ...\file_name is less than or equal to path length limit > Path length of ...\file_name.msf exceeds path length limit In this case, Tb tries to create ...\file_name.msf but it fails. One of the reasons why this kind of issue mainly occurs on MS Win is "very long path of default profile location". >(example of path for INBOX on MS Win XP) > C:\Documents and Settings\username\Application Data\Thunderbird\Profiles\cbz7k273.Trunk-Test\ImapMail\imap.gmail.com\INBOX.msf "C:\Doc...\ImapMail\imap.gmail.com" consumes 116 chars(nearly half of path length limit of MS Win).
Happens to Windows7 too. I have to map a drive as a workaround. From the command line: subst x: /path/to/long/folder
You need to log in before you can comment on or make changes to this bug.