I think this issue has been entirely misunderstood. Have I explained it wrong?
2010/12/22 Karsten Bräckelmann guenther@rudersport.de:
On Wed, 2010-12-22 at 09:34 -0500, Phil Howard wrote:
2010/12/21 Karsten Bräckelmann guenther@rudersport.de:
Creating the new mail folder is entirely on the IMAP server side. The MUA (Evolution in your stated case) is irrelevant. If the creation of the new folder fails, it is a server side problem.
However, once a new folder has been created (server side, mind you), Evolution won't know about that folder until it is restarted. Probably the same with other MUAs, too. In the worst case, restarting Evo twice should show the new folder.
(That is assuming you are not limiting your MUA to subscribed folders only, or, as IIRC is the default, deliver auto-subscribes the user to the just created folder.)
Then I would call this a user agent issue.
You snipped the part of your OP where you stated that dovecot deliver fails creating a mail folder. This is NOT an MUA issue.
Then whose issue it is? There is clearly an issue because an existing folder cannot be accessed by this MUA.
If IMAP provides a way for the user agent to discover the folder already exists, then the user agent should do this, at least if an error is encountered when trying to create it. Evolution clearly does not (or doesn't act on knowing if it does). Other user agents, I don't know. But it is simple logic:
There is a way for the MUA to discover folders existing, LIST. Existing on the IMAP server, mind you, again. So this is not an MUA limitation.
But it would be an MUA issue if the MUA fails to do LIST after an error from CREATE or whatever command it is.
Also, MUAs don't care about the full list of folders, if they are in subscription mode. In that case, they ask for subscribed folders, LSUB, not all folders.
It was not in subscription mode.
Which method do you use? (That's a client option.)
Whatever it starts out as. I don't do subscriptions because so far it hasn't needed to do that. I don't want a subset of folders. I want all folders. How would subscription help there?
if (create folder $name succeeds) OR (folder $name can be accessed) then set up local reference to folder $name
This is unrelated. *sigh* In your case, the creation is server side. And yes, unless you use subscription only, Evo does exactly that on the next start -- ask for all folders on the server.
The point is, if it tries to create a folder, and there is a failure, and because a developer should know and understand that an existing folder is a cause for a failure of a create operation, it should try to distinguish this. A user expects the folder to show up in the list when created when there is no error. If the folder already exists, then there is no valid reason to not put that folder in the list now, just as a successful create would do. Since the protocol apparently provides no means to reflect this situation accurately, the MUA needs to have some means to get access to the existing folder. Restarting the MUA is not an acceptable means.
else report error about creating folder $name endif
Impossible. The error creating the folder occurred on the server, during delivery, which does not even need to be doveot deliver but any number of other MDAs.
No. The delivery successfully created the folder. The error happened later when the MUA tried to create the same folder, due to the MUA not being aware the folder had been created during delivery. But in the case of Evolution, because of that failure in the create operation, it did not allow any access to that folder. The existing folder it tried to create did not get added to the list. It could have been had the logic I described been used. Or it could have been had IMAP provided for a better explain error (more often referred to as "an exceptional condition" in the classic programming methods I originally learned, rather than a pure unexplained error). Still, the MUA could get around that with the suggested logic.
Either way, no client needs to be running while mail is being delivered, and often is not. The server just does not even tell the client about a failure, even *if* it potentially could know about that. This was purely a server-side operation and failure, and the client, any client, is not going to be informed about it.
Only a successfully created folder will be known to the MUA during the LIST command.
If the folder was created by delivery of mail after the MUA was started, and then how do you think an MUA should become aware of that folder ... other than by restarting the MUA which is not an acceptable requirement.
That, of course, depends on IMAP having a means to detect if the folder exists (even though the folder was not given in a previous list of existing folders). Trying to open it should be a way to do that test.
Yes, the IMAP server does detect new folders.
Is this a detection in the sense that the server is notified of the new folder, or simply a context of knowing because a component of the server (deliver) created it?
"Trying to open it" sounds like a client action -- in which case it is just wrong, because the client cannot even try opening something it never knew before existed. Other than brute-force trying all possible char combinations...
When the user is asking for the folder to be created, the user provides a name of the folder. If that folder had been created earlier during deliver, the create step by the MUA will fail because it names the same folder. But the important point right here is that we do have a single folder name. The MUA, after getting an error when it asked for that folder to be created, could still find out if the named folder exists or not be one of at least two method I believe should be available to it: (1) just try to open/access that folder and see if that fails to succeeds. (2) do a LIST (again) and see if that folder name is now in there (was not in an earlier LIST before the delivery happened that created it). I believe method 1 would have the least network traffic.
But if the IMAPD process itself can't or won't even try to access that folder because it wasn't in the list when it started, then I see that as a server side issue, or if the protocol doesn't provide any such means to ask for a folder not previously seen, then I see that as a protocol design issue.
Wow, you really do know what you're talking about, don't you? *sigh*
I do not claim to know the IMAP protocol. I can guess what makes sense for it to have the capability to do.
What I DO know is what makes sense. And one thing that makes sense is that when user of an MUA tries to do a folder creation, when a folder already exists because a successful email delivery created it a few minutes ago, that the MUA should allow the user to access that folder ... even if the create operation done by the MUA through IMAP resulted in an error result returned to the MUA.
In the case of Evolution, that did not happen. It was necessary to completely quit Evolution and start it again to access that folder. Something is bad with that. While I believe it is the fault of the MUA, I was not certain since I do not know the IMAP protocol, or the inner details of Dovecot. I was just seeking a confirmation that it is an MUA issue.
In a nutshell: Failure to create a folder at delivery time is NOT an MUA issue. And whether or not the user will see new folders created successfully depends on (not) limiting to subscribed folders, and the subscription list stored on the server
Basically, exactly what I wrote in my first reply. Mind reading that carefully again?
There was no failure at delivery time. The failure happened when the MUA asked for that folder to be created.
-- sHiFt HaPpEnS!