154928 - incorrect parsing of subfolders on IMAP servers with "." folder separator

Status: RESOLVED DUPLICATE of bug 141744

(MailNews Core :: Networking: IMAP, defect)

Description

[Adrian Corduneanu]

nsImapURI2Path() from nsImapUtils.cpp does not parse correctly URI's containing
subfolders on IMAP servers that use "." as a folder separator.

imap://[e-mail]/INBOX.Sent

should be converted to a local path that looks like

~/.mozilla/temp/02f752ax.slt/ImapMail/po11.mit.edu/INBOX.sdb/Sent.msf

Currently it is converted to a path like:

~/.mozilla/temp/02f752ax.slt/ImapMail/po11.mit.edu/INBOX.Sent.msf

Since other parts of Mozilla handle correctly the "." separator, the bug results
in a mismatch between the folder file written in some circumstances, and read in
others.

Impact:

  copying to a local folder multiple messages from a IMAP subfolder, or
  subfolders with multiple message does not copy the messages on IMAP servers
  that use the "." folder separator

  other possible problems when copying subfolders


Related bugs that reported copying errors of IMAP messages:

  bug #138962, bug #120306 (comment 2)

Actual code that is buggy:

152       nsCAutoString parentName = folder;
153       nsCAutoString leafName = folder;
154       PRInt32 dirEnd = parentName.FindChar('/');
155 
156       while(dirEnd > 0)
157       {
158           parentName.Right(leafName, parentName.Length() - dirEnd -1);
159           parentName.Truncate(dirEnd);
160           NS_MsgHashIfNecessary(parentName);
161           parentName.AppendWithConversion(sbdSep);
162           pathResult += parentName.get();
163       // this fixes a strange purify warning.
164           parentName = leafName.get();
165           dirEnd = parentName.FindChar('/');

The '/' separator should be replaced with the IMAP folder separator of the server.

Comment 1

[Adrian Corduneanu]

The actual bug may not be in nsImapURI2Path() from nsImapUtils.cpp The function
symply assumes the URI received is in cannonical format, which is not the case.

Maybe the bug is that the URI received in
nsCopyMessageStreamListener::OnStartRequest is not in cannonical format (the
separators converted to '/'). 

Comment 2

[Adrian Corduneanu]

Here is the bug:  nsImapUrl::GetUri does not meet its nsIMsgMessageUrl
specification. It should produce a URI in canonical format, with '/' folder
separators, but it does not do that.

Fix: a call to nsImapUrl::ConvertToCanonicalFormat should be placed either in
nsImapUrl::GetUri, or in nsImapUrl::CreateCanonicalSourceFolderPathString
Where to put it depends whether nsImapUrl::CreateCanonicalSourceFolderPathString
is meant to produce a FolderPathString with canonical separators or not. The
name suggests that nsImapUrl::CreateCanonicalSourceFolderPathString should do
the conversion to a canonical format, but maybe I am wrong.

Suggestion:
modify nsImapUrl::GetUri for the mozilla 1.0 branch, and
nsImapUrl::CreateCanonicalSourceFolderPathString for the main trunk. 

Rationale: GetUri is used only in very few contexts, while
CreateCanonicalSourceFolderPathString is extensively used. I am not sure what
coders assumed when they used CreateCanonicalSourceFolderPathString, whether it
really gives a canonical path or not. "Fixing" it could break other things.

Comment 3

[grylchan]

Adrian this sounds like a cyrus imap problem. I added your one
comment to bug 141744.

Karen, I'm going to mark this as dupe of bug 141744.
If you think I am wrong please correct this.

*** This bug has been marked as a duplicate of 141744 ***