Hi, I am trying to deal with the problem, that under regular mbox format a path can lead to either a file or a directory, but not both, while under IMAP, a path is usually both, a message folder containing subfolders. I found dovecot's approach to this problem, the Maildir++ layout described under http://wiki2.dovecot.org/MboxChildFolders , and was astonished to see, what problems come with Maildir++ and how complicated dovecot tries to deal with them. I wonder why dovecot is not using a much easier approach and just uses a configurable prefix and/or suffix like .dir or ____ for directory names, e.g. INBOX -> ~/mail/inbox abc -> ~/mail/abc abc/def -> ~/mail/abc.dir/def or ~/mail/___abc___/def which would make all that trouble with .subscriptions and .index much more easier. In my eyes the Maildir++ layout is overcomplicated because of the heap of workarounds to the self-created problems. regards Hadmut
On Sun, 23 Aug 2015, Hadmut Danisch wrote:> astonished to see, what problems come with Maildir++ and how complicated > dovecot tries to deal with them... [fast fwd to "solution"]> INBOX -> ~/mail/inbox > abc -> ~/mail/abc > abc/def -> ~/mail/abc.dir/def or ~/mail/___abc___/defThis would not work. For example, how would you handle a folder named "abc.dir"? In your scheme, that would end up as ~/mail/abc.dir which would still result in a name clash. How would you handle abc/def/ghi? Something like ~/mail/abc.dir/def.dir/ghi or? That would not make it very workable either. Sounds more like you just introduced a new self-created problem that would require yet another workaround.. ;-) But what was not clear from your mail, is what exactly you identified as "the problems" with standard Maildir++ setup? -- Maarten
On 23 Aug 2015, at 12:25, Hadmut Danisch <hadmut at danisch.de> wrote:> > Hi, > > I am trying to deal with the problem, that under regular mbox format a > path can lead to either a file or a directory, but not both, while under > IMAP, a path is usually both, a message folder containing subfolders. > > I found dovecot's approach to this problem, the Maildir++ layout > described under http://wiki2.dovecot.org/MboxChildFolders , and was > astonished to see, what problems come with Maildir++ and how complicated > dovecot tries to deal with them. > > > I wonder why dovecot is not using a much easier approach and just uses a > configurable prefix and/or suffix like .dir or ____ for directory names, > e.g.It can do it. See: http://wiki2.dovecot.org/MailLocation http://wiki2.dovecot.org/MboxChildFolders
> Sounds more like you just introduced a new self-created problem thatwould require yet another workaround.. ;-) Definitely wrong. Appending .dir to directories and .folder to folder files keeps files completely distinct and name collissions are not possible.> But what was not clear from your mail, is what exactly you identifiedas "the problems" with standard Maildir++ setup? Having regular files filenames beginning with a . is a no-go and flawed by design. Extremely error-prone No serious designer would ever do that. Furthermore, it make it difficult to backup files from particular folder, since not in distinct folder (and thus not mbox-design). Even worse, both folders foo/bar and foo.bar both get the filename .foo.bar Maildir++-setup is broken by design in several ways. That's the problem with Maildir++. Appending smileys doesn't help. Hadmut On 24.08.2015 15:28, Maarten Bezemer wrote:> > On Sun, 23 Aug 2015, Hadmut Danisch wrote: > >> astonished to see, what problems come with Maildir++ and how complicated >> dovecot tries to deal with them. > .. > [fast fwd to "solution"] > >> INBOX -> ~/mail/inbox >> abc -> ~/mail/abc >> abc/def -> ~/mail/abc.dir/def or ~/mail/___abc___/def > > This would not work. > For example, how would you handle a folder named "abc.dir"? In your > scheme, that would end up as ~/mail/abc.dir which would still result > in a name clash. > How would you handle abc/def/ghi? Something like > ~/mail/abc.dir/def.dir/ghi or? That would not make it very workable > either. > > > >