dovecot - Jun 2007 - Sharing nested folders / maildir variations?

Hey all,

So I've got a shared namespace in dovecot where users can, via a  
custom control panel, share their folders into (which creates a  
symlink) in order to allow anyone on their domain to access it.  I  
store mail in maildir.

The issue is that when people share folders, they expect that when  
they make subfolders, those are automatically shared as they are  
contained within it.

According to the Maildir++ specification, "Can folders have  
subfolders, defined in a recursive fashion? The answer is no. If you  
want to have a client with a hierarchy of folders, emulate it. Pick a  
hierarchy separator character, say ":". Then, folder foo/bar is  
subdirectory .foo:bar."  It says some other stupid things too though  
that nobody seems to actually follow, and I've never actually seen  
anything but a '.' used as the delimiter...

The same is true in IMAPdir: "As with Maildir++, submailboxes can not  
be represented in a recursive fashion in the file system. The  
mailbox' representation name will contain the soft hierarchy  
delimiter character dot '.', and all mailboxes must reside in the  
same root level directory."

I don't understand the reasoning behind avoiding recursion,  
honestly.  If somebody wants to enlighten me on that one, it would be  
appreciated.

i.e. instead of:

.Folder/{cur,new,tmp}
.Folder.SubFolder1/{cur,new,tmp}
.Folder.SubFolder1.foo/{cur,new,tmp}
.Folder.SubFolder1.bar/{cur,new,tmp}
.Folder.SubFolder2/{cur,new,tmp}

We'd have:

.Folder/{cur,new,tmp}
.Folder/.SubFolder1/{cur,new,tmp}
.Folder/.SubFolder1/{cur,new,tmp}
.Folder/.SubFolder1/.foo/{cur,new,tmp}
.Folder/.SubFolder1/.bar/{cur,new,tmp}
.Folder/.SubFolder2/{cur,new,tmp}

That would both solve my issue and be a lot more convenient when  
browsing/scripting around maildirs (i.e. "cd ../.foo" vs  
"cd ../.Folder.Subfolder1.foo").

It seems to me that this would be a really easy thing to add support  
for via the config option used to choose between maildir/mbox/dbox.  
Call it rmaildir or somesuch...

Thoughts?

Cheers,
-- 
Casey Allen Shobe | mailto:casey at shobe.info | http://casey.shobe.info
SeattleServer.com, inc. | http://seattleserver.com

On Thu, 2007-05-31 at 22:43 -0700, SeattleServer.com
wrote:
> We'd have:
> 
> .Folder/{cur,new,tmp}
> .Folder/.SubFolder1/{cur,new,tmp}
> .Folder/.SubFolder1/{cur,new,tmp}
> .Folder/.SubFolder1/.foo/{cur,new,tmp}
> .Folder/.SubFolder1/.bar/{cur,new,tmp}
> .Folder/.SubFolder2/{cur,new,tmp}
> 
> That would both solve my issue and be a lot more convenient when  
> browsing/scripting around maildirs (i.e. "cd ../.foo" vs  
> "cd ../.Folder.Subfolder1.foo").
> 
> It seems to me that this would be a really easy thing to add support  
> for via the config option used to choose between maildir/mbox/dbox.  
> Call it rmaildir or somesuch...
Should be already possible with the development version (wonder what I
should call it now that I can't call it CVS HEAD anymore ..
"development", "1.1.UNSTABLE", "hg", ..?):

mail_location = maildir:~/Maildir:LAYOUT=FS

It doesn't use dots anymore then either.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070604/b2a7e63b/attachment-0002.bin>

On 3 Jun, 2007, at 17:03, Timo Sirainen wrote:
> Should be already possible with the development version (wonder what I
> should call it now that I can't call it CVS HEAD anymore ..
> "development", "1.1.UNSTABLE", "hg", ..?):
>
> mail_location = maildir:~/Maildir:LAYOUT=FS
Sweet!
> It doesn't use dots anymore then either.
Do you mean folders don't have to start with a dot?  I started to  
propose that too, but thought I'd be asking for too much.

Specifically, there is a bit in the config:

# By default LIST command returns all entries in maildir beginning  
with a dot.
# Enabling this option makes Dovecot return only entries which are  
directories.
# This is done by stat()ing each entry, so it causes more disk I/O.
# (For systems setting struct dirent->d_type, this check is free and  
it's
# done always regardless of this setting)
maildir_stat_dirs = no

So it seems that removing the dot would break that unless cur/tmp/new/ 
subscriptions/dovecot* started with a dot and folders did not (thus  
reversing the usual convention).  It seemed too much to ask for for  
too little gain, especially as maildrop wouldn't know how to deliver  
to such directories (but maybe it could call deliver).

So what happens if I use the following two together, on a system not  
setting struct dirent->d_type?

mail_location = maildir:~/Maildir:LAYOUT=FS
maildir_stat_dirs = no

Since I have no idea what that actually means, is linux one of the  
systems that does set struct dirent->d_type (JFS filesystem if it  
matters)?

Lastly, any idea how long before this feature can be expected to  
reach production?

Cheers,
-- 
Casey Allen Shobe | mailto:casey at shobe.info | http://casey.shobe.info
SeattleServer.com, inc. | http://seattleserver.com