Re: [Imap-protocol] Creating subfolders in Gmail

Is there a list of these reserved folder names anywhere public?


On Tue, May 27, 2014 at 1:56 PM, Jeff McKay <[email protected]> wrote:

>  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]> 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]> 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]> 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]
>>>>            Phone: +64 3 453-6880 | Fax: +64 3 453-6612
>>>>
>>>> Real newspaper headlines from U.S. papers:
>>>>    TRAFFIC DEAD RISE SLOWLY
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Imap-protocol mailing list
>>>> [email protected]
>>>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Imap-protocol mailing [email protected]://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>>>
>>>
>>>
>>> _______________________________________________
>>> Imap-protocol mailing list
>>> [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
>

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