User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20040910 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20040910 Sometimes when I create a new mail subfolder it is corrupted. What is happening is that the mail program is creating a folder within the mail storage location instead of an empty file with no extension of the same name. What I am having to do is to delete the folder and create an empty file with no extension to correct the problem. Reproducible: Sometimes Steps to Reproduce: 1.Create new sub folder 2.folder does not appear and dialogue box stays open 3. Actual Results: Within the actual email storage location a new folder is created instead of an empty file of the same name Expected Results: Created a new mail storage file The only thing that may be of any usage is the fact that the mail is not stored on my local drive but on a sun work station using SAMBA as a client to host a network drive.

I have found how to recreate this bug reliably. It is similar to the other bugs in the dependency tree as I believe they all stem from one bug in the software. We have just all got to it via a different route. First create a folder. The name is not important. Move this folder to another location or delete it or rename it. Create another new folder with the same name as the first and this is where the bug occurs. I hope this is some help. I would really like to see this bug fixed as it is the only one that prevents me recommending this product to my work colleagues.

Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.7.11) Gecko/20050728 I reproduce this systematically on Windows XP. It seems that the bug depends on the folder pathname size when it is created on the file system. i.e. : I cannot create a mail folder that result in a pathname (in the file system) that is over 256 characters long. On Windows systems, the root of the Mozilla mail storage is generaly located under "C:\Documents and Settings\username\Application Data\Mozilla\Profiles\default\xxxxxx.slt\Mail\". So, the 256 characters long limit is quickly reached when users give explicit names for their mail folders and organize them in deep hierarchical tree. Hope this will help, Regards.

confirmed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060522 SeaMonkey/1.5a TB equivalent is Bug 249807 I see a limit on the SECOND LAST subfolder in depth. I can manage 241 or 242 characters, which theoretically allows for one additional depth of subfolders of the DOS filename of 8+3, plus \ and . - i.e. 13 characters. attempting to go over the limit causes an assert mentioned in Bug 88775 Error: [Exception... "Component returned failure code: 0x8055000b [nsIRDFCompositeDataSource.DoCommand]" nsresult: "0x8055000b (<unknown>)" location: "JS frame :: chrome://messenger/content/mailCommands.js :: DoRDFCommand :: line 51" data: no] Source File: chrome://messenger/content/mailCommands.js Line: 51 [I don't see a relationship that this should block bug 282072 so removing, nor, frankly, a relationship to bug 65303, but keeping it for the moment]

Robert, Can you confirm that your bug is (or not) the same as in comment 2 ? *** MozillaAS v1.7.x is not supported anymore. Thierry, Wayne, Can you reproduce with SeaMonkey v1.1.9 ? Can you reproduce with SeaMonkey v2.0a1pre ?

I currently do not use SeaMonkey. I have switched to Thunderbird. But at some point this problem appears to have been fixed as I have not seen the problem for 6 months or more. The problem was exactly as described in comment 2. This used to be a regular problem for me at work, (occurring at least once a month) but it has not affected me at all recently. Do you think I should change the status of this bug to fixed? Robert

Sorry, I miss read the comments numbers. I suspect comment 2 is actually a different bug to the one I initially reported (however I am no expert so I can't really comment). I am not convinced that my problem was to do with folder lengths. It was more related to bug 65303. Sorry for the confusion. Robert