283446 - Create a new mail subfolder and the dialog does not close and the folder is corrupted

Status: NEW

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Robert Stannard]

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.

Comment 1

[Robert Stannard]

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.

Comment 2

[Thierry Thiers]

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.

Comment 3

[Wayne Mery (:wsmwk)]

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]

Comment 4

[Serge Gautherie (:sgautherie)]

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 ?

Comment 5

[Robert Stannard]

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

Comment 6

[Robert Stannard]

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