Used WinNT 12-21-00-M12 commercial build: This bug is refer to bug#17681, I logged this bug for keep track of all platforms and the UI part. Overview: The UI did not display the consistent folder name "<.....>" when creating folders 1) Login to mail account (ex: IMAP account) 2) Created folder name "<\.....\>" 3) Check the IMAP protocol log file can see the correct folder name "<\.....\>" 4) But tried to check the folder name from the UI. 5) Actual Results: Folder Name is not consistent with the log file, the UI displayed ">" instead of the "<\.....\>". Expected results: Since from bug#17681, "<\.....\>" is the legal folders' name...so the UI should displayed this folder name "<\.....\>" as well.

I have suggestion, this bug's implementation milestone is better set after we can impletement "delete folders". Otherwise, it will keep asking "folder already existed" from the Linux platform when I tried to test or verify for the second time. The winNT didn't display "folder already existed" message... I may need to log another bug for keep track of that!! Thanks.

Reassign to alecf. Since it just fails for this weird name, this doesn't seem like a beta1 stopper. Marking M16

Update this bug's current status by Using 02-28-09-M15 cmmercial build: The Actual Result is as following: The folder name displayed "<\......\" instead of "<\......\>" on the IMAP log & UI which is not correct, the trailing ">" has been truncated.

how is this working these days?

Used today's 04-13-06-M15 commercial build: From Netscape6 UI, it displayed "<\.....\", final ">" disappear on UI (similar to bug#29581) But, from IMAP log, it used to display correctly, but now it is displaying "<\\.....\\" ----------------------------------------------------------------------- 204[2eb3860]: nsmail-5:S-INBOX:SendData: 12 create "<\\.....\\" 204[2eb3860]: nsmail-5:S-INBOX:CreateNewLineFromSocket: 12 OK Completed 204[2eb3860]: nsmail-5:S-INBOX:SendData: 13 subscribe "<\\.....\\" 204[2eb3860]: nsmail-5:S-INBOX:CreateNewLineFromSocket: 13 OK Completed 204[2eb3860]: nsmail-5:S-INBOX:SendData: 14 list "" "<\\.....\\" 204[2eb3860]: nsmail-5:S-INBOX:CreateNewLineFromSocket: * LIST (\HasNoChildren) "/" {8} 204[2eb3860]: nsmail-5:S-INBOX:CreateNewLineFromSocket: <\.....\ 204[2eb3860]: nsmail-5:S-INBOX:CreateNewLineFromSocket: 14 OK Completed 215[361cbf0]: nsmail-5:NA:CreateNewLineFromSocket: * OK tintin.mcom.com IMAP4 service (Netscape Messaging Server 4.1 (built Aug 9 1999)) 215[361cbf0]: nsmail-5:NA:SendData: 1 authenticate plain 215[361cbf0]: nsmail-5:NA:CreateNewLineFromSocket: + 215[361cbf0]: nsmail-5:NA:SendData: AHFhdGVzdDMwAE5lIXNjLXBl 215[361cbf0]: nsmail-5:NA:CreateNewLineFromSocket: 1 OK User logged in (no protection) 215[361cbf0]: nsmail-5:A:SendData: 2 XSERVERINFO MANAGEACCOUNTURL MANAGELISTSURL MANAGEFILTERSURL 215[361cbf0]: nsmail-5:A:CreateNewLineFromSocket: * XSERVERINFO MANAGEACCOUNTURL {63} 215[361cbf0]: nsmail-5:A:CreateNewLineFromSocket: http://qatest30@tintin.mcom.com:9999/bin/user/admin/bin/enduser MANAGELISTSURL NIL MANAGEFILTERSURL NIL 215[361cbf0]: nsmail-5:A:CreateNewLineFromSocket: 2 OK Completed 215[361cbf0]: nsmail-5:A:SendData: 3 select "<\\.....\\" 215[361cbf0]: nsmail-5:A:CreateNewLineFromSocket: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 215[361cbf0]: nsmail-5:A:CreateNewLineFromSocket: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] 215[361cbf0]: nsmail-5:A:CreateNewLineFromSocket: * 0 EXISTS 215[361cbf0]: nsmail-5:A:CreateNewLineFromSocket: * 0 RECENT 215[361cbf0]: nsmail-5:A:CreateNewLineFromSocket: * OK [UIDVALIDITY 955647492] 215[361cbf0]: nsmail-5:A:CreateNewLineFromSocket: 3 OK [READ-WRITE] Completed 215[361cbf0]: nsmail-5:S-<\.....\:SendData: 4 getacl "<\\.....\\" 215[361cbf0]: nsmail-5:S-<\.....\:CreateNewLineFromSocket: * ACL {8} 215[361cbf0]: nsmail-5:S-<\.....\:CreateNewLineFromSocket: <\.....\ qatest30 lrswipcda 215[361cbf0]: nsmail-5:S-<\.....\:CreateNewLineFromSocket: 4 OK Completed -------------------------------------------------------------------------------

Cleanup work, marking M18.

adding b3mail keyword.

Adding nsbeta3 to b3mail bugs.

Removing b3mail keyword (these bugs have been promoted now.)

ugh... putterman? bienvenu?

adding mail3 keyword

changing priorities

marking nsbeta1- because it does not affect a large number of users.

I see what I think is a related problem. Create a local folder named "A/B" (don't include the " characters). If you try to rename it, you get the message: "The folder could not be renamed. Perhaps the folder is being reparsed, or the new name is no a valid folder name." Similarly, attempts to delete such a folder silently fail. I.e., the folder remains shown in the folder tree. It seems like maybe the "new folder" code is using a less restrictive standard than necessary for checking folder names.

>It seems like maybe the "new folder" code is using a less restrictive standard >than necessary for checking folder names. I think so too.

I have the exact same issue as comment #15 but it does not deal with the slashes. Instead, I had a folder with a # in it (abc #123). It is a valid name and Mozilla 1.1 worked with it but when I upgraded to 1.4, the folder was no longer accessible and trying to rename it kept throwing the error that comment #15 has about it being reparsed. Ended up renaming the actual files themselves to remove the #.

Should we look for a way to add the check of '..','.','#',etc in mozilla. Simplely replace them with '_' is ok sometimes when users create folder contains these charactors. Who will recomment a resolute?

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420

Still buggy: <\.....\> gets created as <\.....\ My university's webmailer claims that <\.....\> is an invalid name, so this needs investigation either way.

It fails silently for me (OVH server). Thunderbird 52.1.1 (32-bit) Windows 7 64-bit