On 26.04.2011 23:25, Timo Sirainen wrote:
On 26.4.2011, at 23.48, Binarus wrote:
But whenever a user tries to delete a folder from the public namespace, dovecot gives the following error: "Renaming not supported across non-private namespaces". .. Furthermore, I haven't completely understood the reason for the different behaviour of folders in the public namespace and a single message therein.
Talking only about ACLs I guess it would be ok to allow renaming from public namespace to a private namespace. Renaming one of your own private mailboxes to public namespace is a bit trickier, because the default ACL is "no permissions". So when renaming, a new explicit ACL should be added to the user who did the renaming, because otherwise user could no longer access that mailbox at all. Still doable I guess.
Although it is possible to give user permission to delete foo/bar but not give permission to create children to foo. Then if user renames foo/bar to Trash/foo/bar, it's not possible to rename it back. Probably not a real problem.
Renaming from/to shared namespace needs to update the shared users acl dict.
Quota also needs to be updated. I'm not sure if lazy-expunge has any trouble with this. Multi-dbox backend can't do a fast rename at all, because it would have to physically copy all of the messages from one mdbox storage to another mdbox storage. Maybe there are other problems I can't remember now.
So looks like it should be possible to do all this, with the exception of adding an inefficiency to mdbox, but it's some work..
Thank you very much for your answer which shows that -as always- problems are more complicated than they seem first.
Nevertheless, I don't want to give up, have a few thoughts and just would like to know I am right and what others are thinking:
I have used Cyrus 2.2 for a long time before I switched to Dovecot; in Cyrus 2.2, I did not have the problem. So I am wondering how the problem has been solved there.
Obviously, users can create new folders in public namespace (if the ACL allows) and their private mailboxes; furthermore, they can delete folders from public namespace and private mailboxes (if the ACL allows) (I am talking of a pure delete here, not of moving the folder to Trash).
Thus, we could emulate moving folders between any namespaces (for example, from public namespace to private Trash) by first copying them to the new location and then deleting them from the original location.
Let's assume we have a folder in a public namespace and are allowed to do everything with it. Then, we could delete this folder (this time, I am meaning moving it to private Trash) by doing the following steps manually:
a) Create a new folder with the same name in Trash (which may be in the private mailbox); recursively repeat this with all subfolders.
b) Move all messages from the folder in the public namespace to the folder in Trash; recursively repeat this with all subfolders (remark: moving messages does not seem to cause problems, as opposed to moving folders).
c) Recursively delete the folder with all subfolders (which are completely empty now) from the public namespace (of course, this again is a "real" delete).
I have tested this procedure with multiple IMAP clients against Dovecot, and there were no problems. Automation of the procedure would not be expected to lead to problems, would it?.
- From a user's point of view, it is not important how messages get deleted or moved behind the scenes. A users which wants his stuff moved doesn't care if moving is accomplished by a rename or by another mechanism. In fact, he doesn't even know about renaming. He just wants the stuff which was in some folder to show up in some other folder.
It seems that the problems come from the fact that deletion is done by renaming. I am not in IMAP but suppose that there is some rename command which is used by email clients in such cases. Maybe there is also a delete command which dovecot is "emulating" by doing a rename - I really don't know...
So why not implement the rename / delete command in the way that I have described above? I know that a rename probably (for example on a file system or Dovecot's backends) is by far much more efficient than the copy-move-delete mechanism, but we could do the following:
If the renaming is problematic due to reasons Timo has mentioned in his first reply, then emulate the renaming by the copy-move-delete mechanism; if renaming would be no problem, then use the normal method (the method which is already implemented).
The inefficiency of the copy-move-delete mechanism would be no argument against using it: the alternative would be having the user to do these steps by hand, for every single subfolder (there may be thousands of them...). This is just not acceptable.
One could argue that this functionality should be in the client, and indeed, I suspect that some clients are working that way in some situations. Nevertheless, I think such clients are bad, by using inefficient operations where it would not be necessary and putting the servers under load.
IMHO, such functionality belongs into the server side since only the server can reliably decide if there will be problems before trying the operation.
I am absolutely sure users would prefer waiting for inefficient copy-move-delete operations instead of not being able to move their stuff at all.
Perhaps implementing such a behaviour would not be too difficult?
At the end, I would like to stress that this is not just an academic question. The need to move folders, especially between public and private namespaces, is very common in small and large companies, and although my original post was about deleting folders, the problem in fact is a real big one (although some clients seem to circumvent it by wasting server resources).
I am curiously looking forward to any comments.
Regards,
Peter