Thought I would peek at it while I was checking the busy-loop bug. My guess is that imap/namespace.c, which does some checks, like:
/* first try NAMESPACE_* environments */[...] data = getenv(t_strdup_printf("NAMESPACE_%u", i));
[...]
/* fallback to MAIL */
mail = getenv("MAIL");
if (mail == NULL) {
/* support also maildir-specific environment */
mail = getenv("MAILDIR");[...]
ns->storage = mail_storage_create_with_data(mail, user, flags,
lock_method);Now,
mail_storage_create_with_data(const char *data, const char *user, enum mail_storage_flags flags, enum mail_storage_lock_method lock_method) {
It checks if "data" is NULL/*0, if so call mail_storage_create_default(user, flags, lock_method);
- but that should not happen as the getenv() code checks for NULLs.
It checks to see if mbox: or maildir: prefix is set.
Otherwise, calls, storage = mail_storage_autodetect(data, flags);
if that fails it send the error: if (storage == NULL) { i_error("Ambiguous mail location setting, " "don't know what to do with it: %s " "(try prefixing it with mbox: or maildir:)", data);
Presumably, you do not get that error as it is fatal?
Hence, in autodetect it calls each methods.autodetect function, for example for mbox:
if (*path != '\0' && mbox_is_file(path, "INBOX file", debug))
return TRUE;
if (mbox_is_dir(t_strconcat(path, "/.imap", NULL), "has .imap/", debug))
return TRUE;
if (mbox_is_file(t_strconcat(path, "/inbox", NULL), "has inbox", debug))
return TRUE;
if (mbox_is_file(t_strconcat(path, "/mbox", NULL), "has mbox", debug))
return TRUE;
return FALSE;and for maildir:
path = t_strconcat(data, "/cur", NULL);
if (stat(path, &st) < 0) {
return FALSE;
}
return TRUE;Which would imply that Maildir will only return FALSE for failures, but otherwise default to TRUE. And mbox is the opposite, only returns TRUE if it finds what it likes, otherwise FALSE. So the default appears to be Maildir.
But in your situation, it detects mbox first. Either due to MAIL envvar is set, or, one of the 4 tests return TRUE.
But then, I've only spent 5 minutes on the code, so I don't really know. You'd have to use gdb (or turn on debug output at the very least) to see which path it takes.
What is interesting though is that it appears to iterate the storage classes in order, which appears to be Maildir, mbox, dbox. So, Maildir just fails, but your mbox.autodetect does not fail (or you would get the above error).
Lund
Adam M. Dunn wrote:
Hi all.
Can any C programmers out there tell me how to fix Dovecot to default to Maildir format when autodecting can't find anything? I don't know C, but it seems like it would be a simple thing.
Right now, I use the autodetect mailbox feature because we want users to choose to optionally be able to use Mbox format (we have some diehard unix users with non-maildir clients). I have Maildrop setup to check for the existance of a ~/Maildir folder in the user's home, and if it exists, it delivers there. Otherwise it falls back to ~/Mail where mbox style files go.
The problem with Dovecot is there is no way to tell the autodetect feature what to default to, and if it can't find anything, it automatically creates a folder called ~/mail under the user's home and primes it with an Mbox file, but I'd rather it create a ~/Maildir instead. So if we have for example, a new user with no mail yet, and they log in via IMAP before getting any mail from maildrop, Dovecot will create a them a ~/mail folder. So when they DO get mail, our maildrop filters will think they are an Mbox user. I could do some fancy Maildrop filters to fix that when they get their first mail, but in the meantime the unknowing user could try creating things via IMAP that gets overwritten. Anyway, it would be much cleaner if Dovecot just did what I wanted.
If anyone could point me to the place to patch my copy of Dovecot, I would GREATLY apprecieate it. I don't know C, but I know many other languages.
I would also like to see this be added via the config file in future releases. So consider this a feature request. Not only that, but more control over the autodetection process in general would be REALLY nice.
Thanks. Adam
-- Jorgen Lundman | lundman@lundman.net Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home)