dovecot - Aug 2015 - Shortcomings of Maildir++ layout

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___/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.

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 that
would 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 identified
as "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.
>
>
>
>