Closed Bug 99101 Opened 24 years ago Closed 24 years ago

Lotus IMAP: Doesn't rename hierarchical folders correctly.

Categories

(MailNews Core :: Backend, defect)

All
Windows NT
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.5

People

(Reporter: cavin, Assigned: cavin)

References

Details

(Whiteboard: PDT+)

Attachments

(1 file)

Found the bug while fixing bug 98294. Here is the scenario to reproduce: 1. Login to a Lotus Domino IMAP server (which uses '\' as the delimiter). 2. From folder pane, try to rename folder "k3" to "K35". Note that "k3" is the child folder of "k2" which in turn is a child folder of "k1" (ie, try to rename the 3rd level folder). Actual result: The renamed folder now becomes the 1st level folder. In other words, "k1" and "k35" are at the same level. The protocol log shows that the follow command was issued to the server: 5 rename "k1\\k2\\k3" "k35" This is wrong and the command should have been: 5 rename "k1\\k2\\k3" "k1\\k2\\k35"
Summary: Lotus IMAP: Doens't rename hierarchical folders correctly. → Lotus IMAP: Doesn't rename hierarchical folders correctly.
OK, found the problem. In nsImapService::RenameLeaf() before searching for hierarchy delimiter we should unescape the folder name returned from GetFolderName() because the returned name is in escaped format. In other words, we can never find '\' in a string like "k1%5Ck2%5Ck3" (5C is the hex ASCII code for '\'). A patch is coming soon.
Attached patch proposed patch.Splinter Review
Comment on attachment 48933 [details] [diff] [review] proposed patch. >+ // Unescape the name before looking for parent path >+ nsUnescape(NS_CONST_CAST(char*,(const char*)cStrFolderName.get())); I don't think you need the extra (const char*) cast since the NS_CONST_CAST() takes care of that for you, but I might be wrong.
Yes, you are right.
Ccing naving for review & need bienvenu for sr.
looks ok to me. r=naving
sr=bienvenu
Fix checked in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
This is a low fix interoperability bug with Lotus Domino imap servers which has baked on the trunk. We would like to take this fix on the branch. Re-opening.
Status: RESOLVED → REOPENED
Keywords: nsbranch+
Resolution: FIXED → ---
Target Milestone: --- → mozilla0.9.5
Blocks: 99508
Per PDT meeting today this bug is PDT+
Whiteboard: PDT+
Fix checked into branch.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Verified WinNT 09-17-05-0.9.4 build Now, after renamed the 3rd subfolders, it stay at the same 3rd level and from the IMAP log, it display correctly now. Marking as verified. ----------------------------------------------------------------------------- 148[4eae2e0]: 198.112.211.44:A:SendData: 13 rename "c1\\c2\\c3" "c1\\c2\\c35" 148[4eae2e0]: 198.112.211.44:A:CreateNewLineFromSocket: 13 OK RENAME completed 148[4eae2e0]: 198.112.211.44:A:SendData: 14 subscribe "c1\\c2\\c35" 148[4eae2e0]: 198.112.211.44:A:CreateNewLineFromSocket: 14 OK SUBSCRIBE completed 148[4eae2e0]: 198.112.211.44:A:SendData: 15 unsubscribe "c1\\c2\\c3" 148[4eae2e0]: 198.112.211.44:A:CreateNewLineFromSocket: 15 OK UNSUBSCRIBE completed 148[4eae2e0]: 198.112.211.44:A:SendData: 16 subscribe "c1\\c2\\c35\\c3-1" 148[4eae2e0]: 198.112.211.44:A:CreateNewLineFromSocket: 16 OK SUBSCRIBE completed 148[4eae2e0]: 198.112.211.44:A:SendData: 17 unsubscribe "c1\\c2\\c3\\c3-1" 148[4eae2e0]: 198.112.211.44:A:CreateNewLineFromSocket: 17 OK UNSUBSCRIBE completed 148[4eae2e0]: 198.112.211.44:A:SendData: 18 subscribe "c1\\c2\\c35\\c4" 148[4eae2e0]: 198.112.211.44:A:CreateNewLineFromSocket: 18 OK SUBSCRIBE completed 148[4eae2e0]: 198.112.211.44:A:SendData: 19 unsubscribe "c1\\c2\\c3\\c4" 148[4eae2e0]: 198.112.211.44:A:CreateNewLineFromSocket: 19 OK UNSUBSCRIBE completed 148[4eae2e0]: 198.112.211.44:A:SendData: 20 subscribe "c1\\c2\\c35\\c4\\c4-1" 148[4eae2e0]: 198.112.211.44:A:CreateNewLineFromSocket: 20 OK SUBSCRIBE completed 148[4eae2e0]: 198.112.211.44:A:SendData: 21 unsubscribe "c1\\c2\\c3\\c4\\c4-1" 148[4eae2e0]: 198.112.211.44:A:CreateNewLineFromSocket: 21 OK UNSUBSCRIBE completed 148[4eae2e0]: 198.112.211.44:A:SendData: 22 select "c1\\c2\\c35" 148[4eae2e0]: 198.112.211.44:A:CreateNewLineFromSocket: * 0 EXISTS 148[4eae2e0]: 198.112.211.44:A:CreateNewLineFromSocket: * 0 RECENT 148[4eae2e0]: 198.112.211.44:A:CreateNewLineFromSocket: * OK [UIDVALIDITY 71] UIDs valid 148[4eae2e0]: 198.112.211.44:A:CreateNewLineFromSocket: * OK [UIDNEXT 1] Predicted next UID 148[4eae2e0]: 198.112.211.44:A:CreateNewLineFromSocket: * FLAGS (\Flagged \Seen \Answered \Deleted \Draft) 148[4eae2e0]: 198.112.211.44:A:CreateNewLineFromSocket: * OK [PERMANENTFLAGS (\Flagged \Seen \Answered \Deleted \Draft \*)] Permanent flags 148[4eae2e0]: 198.112.211.44:A:CreateNewLineFromSocket: 22 OK [READ-WRITE] SELECT completed --------------------------------------------------------------------------------
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: