[Dovecot] 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@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.
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@shobe.info | http://casey.shobe.info SeattleServer.com, inc. | http://seattleserver.com
On Sun, 2007-06-03 at 23:10 -0700, SeattleServer.com wrote:
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 doesn't break, but it does mean that you aren't able to create mailboxes named "cur", "tmp", "new", "subscriptions", etc.
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
LAYOUT=FS uses completely different code (same as mbox listing) and doesn't use maildir_stat_dirs at all.
Lastly, any idea how long before this feature can be expected to
reach production?
v1.1 is hopefully ready at the end of this summer.
participants (2)
-
SeattleServer.com
-
Timo Sirainen