Re: [evolution-patches] seeking review for patch for bug 55102

[Not Zed <notzed ximian com>]

On Sat, 2004-03-13 at 08:43 -0500, Jeffrey Stedfast wrote:

> On Sat, 2004-03-13 at 05:11, Not Zed wrote:
> > Also check the bug.  I closed it since it actually works in 1.5.x (or
> > one very like it), since the correct fix has actually been applied
> > (although may be incomplete).
> > 
> > '%' is still an issue.  I'm not sure of the  best fix for it yet.  It
> > may just be practical to disable its use (if existing folders use it it
> > is ok, but if you create a new folder it wont).
> 
> Actually I fixed the % issue for local folders. the problem was that
> mbox/mh/maildir stores weren't properly encoding the fragment.
> 
> the IMAP code is the only one left to fix, and that code seems as though
> it is hex decoding the 'name'. According to your comments in bugzilla,
> it is doing this on purpose because it is expecting the mail/ code to be
> hex escaping certain chars in the names? which chars is it expecting to
> be hex escaped? I think I remember something about hex escaping '/' so

No.  It isn't expecting anything to be escaped.

It encodes specific things inside the imap code between the server and
the application.  And it reencodes them back again, so the application
code should never know the difference.  Its just that it uses % to do
this, so using % in create_folder will conflict.

> that IMAP servers that didn't use '/' as their dir-sep could use that
> char in the folder name, but this hack is no longer needed with the new
> tree code (since it doesn't use path strings to populate the tree).
> 
> I guess we'd still have to worry about code that tried to use the
> fi->path to figure out the basename/etc.

But nothing does.  This is a different problem which is solved
internally to imap.