Re: [Imap-protocol] Creating subfolders in Gmail

Thanks.  Bad luck and ignorance on my part to have picked a reserved 
folder name to test, but it's good to know that it works
the way I thought it did.

On 5/27/2014 1:39 PM, Jamie Nicolson (倪志明) wrote:
> Ah, yes, "Migrated" matches a Gmail system label (like Inbox, Sent, 
> etc), and therefore it is aliased to [IMAP]/Migrated in the web 
> interface. Note that you can't even create a label named "Migrated" in 
> the web interface; you'll get the error, "The label name Migrated is 
> invalid." The same thing would happen if your top-level folder were 
> named Sent, Spam, Trash, etc. This shouldn't effect how things work in 
> IMAP, but will change how they are displayed in the web interface.
>
>
> On Tue, May 27, 2014 at 1:22 PM, Jeff McKay <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     It is the second case I am trying to implement, where in the UI, I
>     can see bar nested under foo.  That does not appear to work
>     as you stated.   Here is the trace of me creating two folders:
>
>     <send 24>A103 CREATE "Migrated"
>     <recv 17>A103 OK Success
>     <send 43>A104 CREATE "Migrated/BUDGET CALCULATION"
>     <recv 17>A104 OK Success
>     <send 89>A001 APPEND "Migrated/BUDGET CALCULATION" (\Seen)
>     "18-Apr-2014 09:49:00 -0700" {135007}
>     <recv 12>+ go ahead
>
>     When I get a new list, I see this:
>
>     * LIST (\HasChildren) "/" "Migrated"
>     * LIST (\HasNoChildren) "/" "Migrated/BUDGET CALCULATION"
>
>     So it would have appeared to work, but, the UI displays only
>     "Migrated/BUDGET CALCULATION".    There is also another
>     label called "[IMAP]/Migrated" with nothing in it.
>
>
>     On 5/27/2014 12:40 PM, Jamie Nicolson (倪志明) wrote:
>>     I'm not sure what you mean by "single top level folder".
>>     "foo/bar" has the hierarchy delimiter in it, so from IMAP's point
>>     of view it is a nested folder.
>>
>>     If you want to be able to store messages in "foo/bar", but not
>>     "foo", you can CREATE foo/ and then CREATE foo/bar. The first
>>     CREATE will be a no-op on Gmail, but will succeed with OK. The
>>     second CREATE will result in this folder layout:
>>
>>     * LIST (\Noselect \HasChildren) "/" "foo"
>>     * LIST (\HasNoChildren) "/" "foo/bar"
>>
>>     Now you can COPY and APPEND messages to foo/bar. If you also want
>>     to be able to store messages directly in foo, you just have to
>>     CREATE foo (without the hierarchy delimiter suffix). You can do
>>     this before or after creating "foo/bar". Then you'll have this:
>>
>>     * LIST (\HasChildren) "/" "foo"
>>     * LIST (\HasNoChildren) "/" "foo/bar"
>>
>>     The web UI displays these two cases differently. In the first
>>     case (where foo/bar is selectable but foo is \Noselect), we show
>>     "foo/bar" as a standalone label. In the second case (where
>>     foo/bar and foo are both selectable folders), we display bar
>>     nested under foo. This is just a quirk of the web UI.
>>
>>
>>     On Tue, May 27, 2014 at 12:14 PM, Jeff McKay <[email protected]
>>     <mailto:[email protected]>> wrote:
>>
>>         Yes that is what I get also, sorry for misstating the error
>>         message.  I am still unclear though about how to create a folder
>>         with a sub-folder.  You said that the correct syntax should be:
>>
>>         CREATE "foo/bar"
>>
>>         which creates a single top level folder called "foo/bar".   I
>>         know that you want to support being able to create folder names
>>         that contain the hierarchy delimiter,  but there seems to be
>>         a conflict here.
>>
>>
>>         On 5/27/2014 11:09 AM, Jamie Nicolson (倪志明) wrote:
>>>         I don't see any error message in the Gmail code for
>>>         "hierarchy character ignored". When I try to reproduce this,
>>>         I see something different:
>>>
>>>         a create foo/
>>>         a OK [CANNOT] Ignoring hierarchy declaration (Success)
>>>
>>>         This seems to follow 6.3.3.
>>>
>>>
>>>         On Fri, May 23, 2014 at 9:09 PM, David Harris
>>>         <[email protected]
>>>         <mailto:[email protected]>> wrote:
>>>
>>>             On 23 May 2014 at 18:03, Jeff McKay wrote:
>>>
>>>             > Has something changed with how Gmail handles the
>>>             hierarchy character
>>>             > in the CREATE command? I am sure I had this working at
>>>             one point, but
>>>             > now:
>>>             >
>>>             > CREATE "TopLevelFolder/"
>>>             >
>>>             > generates "NO hierarchy character ignored"
>>>
>>>             The server would appear to be in error. See RFC3501,
>>>             section 6.3.3 ("The
>>>             Create Command"):
>>>
>>>                   If the mailbox name is suffixed with the server's
>>>             hierarchy
>>>                   separator character (as returned from the server
>>>             by a LIST
>>>                   command), this is a declaration that the client
>>>             intends to create
>>>                   mailbox names under this name in the hierarchy.
>>>              Server
>>>                   implementations that do not require this
>>>             declaration MUST ignore
>>>                   the declaration.  In any case, the name created is
>>>             without the
>>>                   trailing hierarchy delimiter.
>>>
>>>             This seems pretty unambiguous to me, but no doubt
>>>             there's an alternative
>>>             reading I haven't considered (there usually is). I
>>>             assume GMail actually
>>>             *does* support submailboxes (I don't personally use it)?
>>>
>>>             Interestingly, the example for section 6.3.3 is an
>>>             almost exact match to your
>>>             report:
>>>
>>>                   Example:
>>>                      C: A003 CREATE owatagusiam/
>>>                      S: A003 OK CREATE completed
>>>
>>>             Note that there is a reverse condition to this where a
>>>             server may report a
>>>             mailbox with a trailing hierarchy delimiter as part of a
>>>             LIST response; I
>>>             confess I've never understood exactly what that means
>>>             (Exchange used to
>>>             do it and may still do so) - Mark Crispin once explained
>>>             it to me as having
>>>             some meaning related to a test for existence, but I
>>>             couldn't grasp what he
>>>             meant.
>>>
>>>             Cheers!
>>>
>>>             -- David --
>>>
>>>             ------------------ David Harris -+- Pegasus Mail
>>>             ----------------------
>>>             Box 5451, Dunedin, New Zealand | e-mail:
>>>             [email protected] <mailto:[email protected]>
>>>                        Phone: +64 3 453-6880
>>>             <tel:%2B64%203%20453-6880> | Fax: +64 3 453-6612
>>>             <tel:%2B64%203%20453-6612>
>>>
>>>             Real newspaper headlines from U.S. papers:
>>>                TRAFFIC DEAD RISE SLOWLY
>>>
>>>
>>>
>>>             _______________________________________________
>>>             Imap-protocol mailing list
>>>             [email protected]
>>>             <mailto:[email protected]>
>>>             http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         Imap-protocol mailing list
>>>         [email protected]  <mailto:[email protected]>
>>>         http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>>
>>
>>         _______________________________________________
>>         Imap-protocol mailing list
>>         [email protected]
>>         <mailto:[email protected]>
>>         http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>>
>>
>
>

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol