Re: [Imap-protocol] Creating subfolders in Gmail
Jeff McKay <[email protected]> Tue, 27 May 2014 16:58:54 -0700
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <[email protected]> |
The LIST command will show the various system folders, under the top level "[Gmail]". Trash is there, but I don't see "Migrated". I can avoid using folder names from that subset, but it does not seem to be complete. On 5/27/2014 2:14 PM, Jamie Nicolson (倪志明) wrote: > Unfortunately, no. It's a big set, consisting of every translation of > every system label. For example, you can't create a label named > "Trash" (US English), and neither can you create one named "Bin" (UK > English) or "Corbeille" (French). Since our translations are subject > to change, and we may add system labels in the future, we don't want > to publish a static list somewhere that would quickly become out of > date. It might be possible to add a special result code to the CREATE > response indicating that the folder name will be aliased. Would that > be useful? > > > On Tue, May 27, 2014 at 2:00 PM, Michael Grinich <[email protected] > <mailto:[email protected]>> wrote: > > Is there a list of these reserved folder names anywhere public? > > > On Tue, May 27, 2014 at 1:56 PM, Jeff McKay <[email protected] > <mailto:[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] <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] > <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