Yes, just write a dummy message, select the mailbox, and store the flags.Is there a good place in imapd we can hack "Junk" into the default keywords available for all newly created (in our case, mbx format) mailboxes?That's ok if you're writing a new proprietary client, but not for users creating mailboxes the normal way.
That doesn't make any sense. If your client has a list of keywords that it wants in all mailboxes, it is perfectly capable of acting as I suggest.
* FLAGS (\Answered \Flagged \Deleted \Draft \Seen) * OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags Yuck. Looks like those are hardcoded and do not appear in the mbx file at all. Only newly defined ones do. Any hope?
Of course \ flags are hardcoded. That's a requirement of the IMAP specification. You'll notice that keywords don't start with a \.
I do see that . store 999999 +FLAGS (Junk) Succeeds in creating the "Junk" flag even if no message 999999 exists.
You can not count upon that behavior. It's a bug that UW imapd does an action on a command that returns a tagged NO. Now that I know about that bug, I'm fixing it. Thank you for letting me know about it.
Incidentally, the error message you get when trying to DELETE a currently selected mailbox is a little misleading. It's not "another" process, it's the current process. This annoys users when they try to delete an empty mailbox from a GUI client.
Yes, some GUI clients have bugs.
So should client authors "have known" that they need to unselect a mailbox otherwise in use?
Yes. Of course.
If you think about it, it doesn't make sense to have a selected mailbox that has been deleted, given the other semantics of mailboxes (which are different from UNIX file semantics).
What about servers (including uw imapd until recently) that don't implement UNSELECT?
The client shouldn't have selected the mailbox first if it was going to delete it.
It isn't guaranteed that error messages will always be precise for every possible thing that goes wrong. Often, as in this case, a well-intentioned effort to provide user-friendly information, as opposed to unintelligible (but precisely accurate) errors, can result in an error message that is not strictly accurate.
The library does not know what has it open, nor does it have a reasonable way to find out. It just knows that it's locked as an open mailbox. It guesses that the culprit is another process, since surely no program would be foolish enough to delete something that it has open.
The true error condition is "Mailbox locked". Most users would have a completely incorrect understanding of what that means, and how to remedy it.
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
