On Fri, 2008-10-31 at 12:52 +0100, Bernhard Herzog wrote:
On 28.10.2008, Bernhard Herzog wrote:
List with "%" doesn't list all intermediate mailboxes.
On the one hand arthur sees this:
x LIST "" "*" ...
- LIST (\Noselect \HasChildren) "/" "users/ford"
- LIST (\HasNoChildren) "/" "users/ford/INBOX/hhgttg" x OK List completed.
OTOH, with "%" only this:
x LIST "" "users/ford/%" x OK List completed.
I've looked into this. The problem is that acl_mailbox_list_info_is_visible in src/plugins/acl/acl-mailbox-list.c considers nonexistent mailboxes as not visible. The attached patch fixes that for me. I'm not sure it really is the right fix, though. Maybe it would cause some mailboxes to be listed even though they shouldn't.
Right, it could (would) cause mailboxes to be listed that aren't supposed to be listed. I think you'll also have a problem if e.g. "foo" exists but doesn't have 'l' right and "foo/bar" exists and has 'l' right. I think % will currently not list "foo". If it behaved correctly it should list it as non-existing mailbox.
The real solution would be to find out if there are any visible child mailboxes. That's kind of annoying to implement though. You'll only need to do that if the mailbox list pattern expects that mailbox to be returned. For example with the above foo and foo/bar mailboxes:
LIST % -> List "foo" as non-existing LIST foo -> List "foo" as non-existing LIST * -> List "foo/bar" only
I'm not exactly sure what's the right way to implement this. That's why it's still in my TODO list instead of actually implemented. :)
There's one thing about acl_mailbox_list_info_is_visible and struct acl_mailbox_list_iterate_context that I don't understand. What's the member struct mailbox_info info; used for?
Looks like it's a bug. Perhaps I moved some of the code to acl_mailbox_list_info_is_visible() which broke it. The idea was anyway to modify info.flags and store them to ctx->info and then return ctx->info from the function. But that's clearly not happening.
Fixed: http://hg.dovecot.org/dovecot-1.2/rev/692aac54ae1c
..and I immediately noticed that's buggy too, so..: http://hg.dovecot.org/dovecot-1.2/rev/ca4e277a6615