dovecot - May 2010 - mdbox: Cannot create subfolder called "dbox-Mails" (2.0beta5)

I am trying out "mdbox" under Dovecot 2.0beta5.

Looking in the "mailboxes" directory under the mdbox storage root 
("~/dbox" in my case), I can see that the mail folders are mapped into
filesystem directories.

But Dovecot seems to put all the message list information 
("dovecot.index.cache", "dovecot.index.log") for any given
mail folder
into a directory called "dbox-Mails"...

But this directory name exists in the same namespace as that used for 
mail subfolders...

So this means we cannot create a mail subfolder whose name is
"dbox-Mails"!

I concede that this eventuality may be unlikely, but when designing in a 
green field, surely we should avoid such obvious pitfalls?

Surely we would want to make it so that these objects exist in different 
namespaces, so that mail folders can be created with any name?

So perhaps the directory "dbox-Mails" should use a character in its
name
which could not be used in mail folder names.

Or mail folder names could have a non-identity mapping into directory 
names such that the directory name can never be "dbox-Mails".

Regards,

Bill

On to, 2010-05-13 at 10:14 +0100, William Blunn wrote:
> So this means we cannot create a mail subfolder whose name is
"dbox-Mails"!
Yes. That's why it's called dbox-Mails, it's unlikely people will
want
to try to create it :)
> I concede that this eventuality may be unlikely, but when designing in a 
> green field, surely we should avoid such obvious pitfalls?
> 
> Surely we would want to make it so that these objects exist in different 
> namespaces, so that mail folders can be created with any name?
Those conflict with how people often want to manage mailboxes on
filesystem..
> So perhaps the directory "dbox-Mails" should use a character in
its name
> which could not be used in mail folder names.
Only such characters are control characters. Admins wouldn't be very
happy with those. Maybe some filesystems wouldn't allow them either (I
know OSX has some limitations).
> Or mail folder names could have a non-identity mapping into directory 
> names such that the directory name can never be "dbox-Mails".
There could be some escaping, but just to allow dbox-Mails mailbox name
that seems overly complex.

The final solution in future would be to prefer using mailbox GUIDs as
the directory names. This fixes some other bugs as well related to
swapping one mailbox to another while it's already open in one session.
But it also pretty much requires mailbox list indexes, so it's not
possible yet.

On 13/05/2010 10:14, William Blunn wrote:
> I am trying out "mdbox" under Dovecot 2.0beta5.
>
> Looking in the "mailboxes" directory under the mdbox storage root
> ("~/dbox" in my case), I can see that the mail folders are mapped
into
> filesystem directories.
>
> But Dovecot seems to put all the message list information 
> ("dovecot.index.cache", "dovecot.index.log") for any
given mail folder
> into a directory called "dbox-Mails"...
>
> But this directory name exists in the same namespace as that used for 
> mail subfolders...
>
> So this means we cannot create a mail subfolder whose name is 
> "dbox-Mails"!
Looking at some new (1 Sep 2010) documentation from Timo at 
http://wiki2.dovecot.org/MailLocation, it looks like in the meantime we 
have grown a new configuration directive "DIRNAME" which can be used
in
the mailbox location specification to change the metadata directory name 
to something other than the default "dbox-Mails".

So if site mail admins are concerned about clashes with user mail 
folders called "dbox-Mails" they can choose another name for the 
metadata directory.

OK fine so far, but then I saw the next bit.

We can also use "DIRNAME" with Maildir (if we have also specified 
LAYOUT=fs) to specify that {new,cur,tmp} folders should be stored in a 
subdirectory named by DIRNAME. This prevents clashes between user mail 
folder names and the {new,cur,tmp} folders. It is then up to the site 
admin to choose a value for DIRNAME which they think won't clash with 
user mail folder names.

OK, but then it occurred to me, if we can use DIRNAME with Maildir, how 
about LAYOUT with dbox?

How about having the ability to specify Maildir++ folder layout under 
dbox? For example:

# Note: Following configuration line is hypothetical
mail_location = mdbox:~/mdbox:LAYOUT=maildir++

~/mdbox/mailboxes/dbox-Mails  (mail folder INBOX)
~/mdbox/mailboxes/.foo/dbox-Mails  (mail folder foo)
~/mdbox/mailboxes/.foo.bar/dbox-Mails  (mail folder foo/bar)
~/mdbox/mailboxes/.foo.bar.baz/dbox-Mails  (mail folder foo/bar/baz)

One upshot of this would be that user folder names would be in a 
different namespace to the DIRNAME folder.

Also for admins who prefer fewer filesystem directory levels, this would 
make them happy because all the mail folder levels would be at a single 
directory level in the filesystem.

I suppose another upshot would be that it would look more like 
Maildir++, which admins may already be familiar with, and might provide 
a smoother/easier (mental) transition to dbox for admins.

Bill

On 4.9.2010, at 11.40, William Blunn wrote:
> OK, but then it occurred to me, if we can use DIRNAME with Maildir, how
about LAYOUT with dbox?
> 
> How about having the ability to specify Maildir++ folder layout under dbox?
For example:
You can.

On 04/09/2010 16:37, Timo Sirainen wrote:
> On 4.9.2010, at 11.40, William Blunn wrote:
>    
>> OK, but then it occurred to me, if we can use DIRNAME with Maildir, how
about LAYOUT with dbox?
>>
>> How about having the ability to specify Maildir++ folder layout under
dbox? For example:
>>      
> You can.
>    
I had an idea you might say that :-)

Bill

On Mon, 2010-09-06 at 16:35 +0100, Timo Sirainen wrote:
> On Mon, 2010-09-06 at 16:01 +0100, William Blunn wrote:
> 
> > Sep  6 14:41:08 pod dovecot: lda(bill): Error: user bill:
Initialization
> > failed: Initializing mail storage from mail_location setting failed: 
> > Mailbox list driver maildir++: maildir_name not supported by this
driver
> 
> This should help: http://hg.dovecot.org/dovecot-2.0/rev/b00d3a367d79
Oh, also add :DIRNAME=