Re: public and shared folder identifiers are not displayed as directories

The simple answer is that it is a bug in Mozilla.

#public is not a "folder".  It is a namespace.

Think of a namespace as like an A: drive in Windows.  If, and only if, 
there is a floppy inserted on your PC, you can reference names in a 
separate hierarchy starting with A:

A namespace similiarly identifies a separate hierarchy that may exist. 
If, and only if, that hierarchy actually exists, you can references names 
that start with that namespace name.

In UW IMAP, the namespace #public identifies a hierarchy whose root is the 
home directory of user imappublic.  Thus, #public/foo is exactly 
equivalent to ~imappublic/foo.

If the IMAP client LISTs #public/*, one of two things will happen:
  [1] No results.  The user imappublic does not exist.
  [2] The contents of the home directory of user imappublic.

In the case of [2], you will see "#public/" returned as a \NoSelect name, 
as this is the root of the #public space.

#public/#public is simply nonsense.  Something concatenated #public twice. 
UW IMAP will never do that, so it must have been Mozilla.

Perhaps Mozilla was attempting to apply a "prefix"; if so, it did it 
incorrectly.  The correct way to apply a "prefix" is to use the reference 
field of the LIST command.  That is, given a "prefix" of "#public/" and a 
request to open "#public#":

Wrong:	concatenate "#public/" and "#public", forming "#public/#public"

Correct: in IMAP, do the command:
 	tag LIST #public/ #public
and use the name that is returned from LIST.  If no name is returned, 
there is no such name.

In conclusion, this is completely a bug in Mozilla.  I should also mention 
that this comment in bug 497096 that claims a server bug is also 
completely wrong:

> 5 list "" "Trash/emu2000/*"
> * LIST (\HasNoChildren) "/" "Trash/emu2000/"
(B) This response means folder named <null> under emu2000 under Trash.
     Folder name in response has to be correct name which can be specified in
     SELECT commant etc. So this is apparently server side bug.

There is no such thing as a "folder named <null>".  The LIST response here 
simply confirms that Trash/emu2000 exists as a directory.  Otherwise, 
there would be no way to distinguish "directory empty" from "directory 
does not exist".

The bottom line is that if a client developer claims that there is a bug 
in UW IMAP, he is almost always wrong; and is confused by a subtle aspect 
of the IMAP protocol.


On Sat, 2 Jan 2010, Juergen Edner wrote:
> Hello,
> I'm using uw-imapd 2007b on my mail server. For quite a while
> I'm now using public/shared folders to share information between
> different users or provide a central spam mailbox.
>
> This is e.g. my folder/mailbox structure:
>
> #public         -> folder
>   + Spam-Mail  -> mailbox
>
> Sometimes I'm erroneously selecting the #public (or #shared)
> folder in my Thunderbird client which causes the following
> error message:
>
>  Can't open mailbox #public/#public: no such mailbox
>
> I raised a bug request for TB but based on the following
> discussion of the developers this problem seems to be a
> uw-imapd problem because the server doesn't return a
> \NoSelect if such a folder is selected.
>
> Here you can find further debug information and the discussion
> of the problem:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=517054
>
> Now I wonder if this is really a problem of uw-imapd and
> if so, how it can be solved?
>
> Thanks
> Juergen
> -- 
> Mail: [email protected]
> _______________________________________________
> Imap-uw mailing list
> [email protected]
> http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
>

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw