On Fri, 21 Feb 2003, Charlie Brady wrote: >On Fri, 21 Feb 2003, Andreas Aardal Hanssen wrote: >> On Thu, 20 Feb 2003, Charlie Brady wrote: >> >On Thu, 20 Feb 2003, Andreas Aardal Hanssen wrote: >> We'll have to do something smart. >Why will we have to do anything at all? If someone creates a directory >./.INBOX (or ./.InBox, or ./.iNbOX, or /tmp/foo) why does bincimap care at >all? What matters is bincimap's interaction with a client, and if a client >selects "INBOX", or "InBox" or "iNbOX" then this must be interpreted as >accesses to ~/Maildir/, not to ./.INBOX, or ./InBox, etc. >AFAICT the existance of a directory ./.INBOX is irrelevant to bincimap. I >don't understand why you are worrying about it.
Then I'll explain what I'm worried about. If Maildir/ is to be interpreted as INBOX, and Maildir/.INBOX.hello/ is to be interpreted as INBOX/hello, ...what should Maildir/.INBOX/ be interpreted as? Ignoring it is not an option. Today, Binc will advertise it as INBOX.INBOX - a true subfolder of INBOX whose name is also INBOX. Two different folders. >> INBOX/INBOX maps by Maildir++ conventions to ./Maildir/.INBOX/, FWICS. >Not by Maildir++ conventions AFACIT. Perhaps this mapping is used by the >Courier implementation, because "INBOX" is the personal namespace, and is >therefore stripped before the Maildir++ mapping. Can someone who runs >Courier confirm this? If INBOX is truly a namespace only, then selecting INBOX only, not INBOX.INBOX, does not make sense to me. In Courier-IMAP, INBOX and INBOX.INBOX are equivalent. How is that for consistency? 2 LIST "" "INBOX" * LIST (\Unmarked \HasChildren) "." "INBOX" 2 OK LIST completed 2 LIST "" "INBOX.INBOX" 2 OK LIST completed 3 CREATE "INBOX.INBOX" 3 NO Cannot create this folder. Ok - that makes sense. 3 LIST "" INBOX.INBOX 3 OK LIST completed So it's not there, yet I can select it. 4 SELECT "INBOX.INBOX" * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent) * OK [PERMANENTFLAGS (\Draft \Answered \Flagged \Deleted \Seen)] Limited * 2254 EXISTS * 2254 RECENT * OK [UIDVALIDITY 1045844866] Ok 4 OK [READ-WRITE] Ok 5 CLOSE 5 OK mailbox closed. 6 SELECT INBOX * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent) * OK [PERMANENTFLAGS (\Draft \Answered \Flagged \Deleted \Seen)] Limited * 2254 EXISTS * 0 RECENT * OK [UIDVALIDITY 1045844866] Ok 6 OK [READ-WRITE] Ok Those two are the same mailbox, accessed with two different names. Now if I create a Maildir++ subdirectory called INBOX, that is, Maildir/.INBOX/, this happens: 7 LIST "" "INBOX.INBOX" * LIST (\HasNoChildren) "." "INBOX.INBOX" So Courier-IMAP suddenly advertises this mailbox as selectable. What happens if I select this new mailbox that suddenly showed up? 8 SELECT INBOX.INBOX * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent) * OK [PERMANENTFLAGS (\Draft \Answered \Flagged \Deleted \Seen)] Limited * 2254 EXISTS * 0 RECENT * OK [UIDVALIDITY 1045844866] Ok 8 OK [READ-WRITE] Ok Hey - since INBOX and INBOX.INBOX are equivalent in Courier-IMAP, it _will_ display it in LIST but not allow me to select it. 9 STATUS INBOX (MESSAGES) * STATUS "INBOX" (MESSAGES 2254) 10 STATUS INBOX.INBOX (MESSAGES) * STATUS "INBOX.INBOX" (MESSAGES 2254) Where's my new mailbox? Why did Courier-IMAP first _not_ advertise INBOX.INBOX, then when I created it with another client, it _did_ advertise it, but it won't let me select it. Now I'm curious about this command: 11 RENAME INBOX INBOX.INBOX 11 NO This feature is not yet supported. This is also funny: 11 CREATE INBOX.INBOX.INBOX 11 OK "INBOX.INBOX.INBOX" created. 12 LIST "" "*" * LIST (\HasNoChildren) "." "INBOX.INBOX.INBOX" * LIST (\HasNoChildren) "." "INBOX.qconfirm" * LIST (\HasNoChildren) "." "INBOX.Trash" * LIST (\Marked \HasChildren) "." "INBOX" * LIST (\Noselect \HasChildren) "." "INBOX.INBOX" 12 OK LIST completed So INBOX.INBOX is not selectable? Yet - 13 SELECT INBOX.INBOX * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent) * OK [PERMANENTFLAGS (\Draft \Answered \Flagged \Deleted \Seen)] Limited * 1344 EXISTS * 0 RECENT * OK [UIDVALIDITY 1012945786] Ok 13 OK [READ-WRITE] Ok This is the sort of brain dead behavior that I will not have in Binc IMAP. So ignoring that mailbox, or disallowing a SELECT, hiding it and so on, does not work. For now, Binc will only allow submailboxes of INBOX, until we can agree on a proper way to support root level mailboxes. Andy -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | Nil desperandum
