On Mon, Jun 04, 2007 at 03:47:13PM +0300, Timo Sirainen wrote:
On Sun, 2007-06-03 at 23:05 -0400, Adam McDougall wrote:
On Mon, Jun 04, 2007 at 05:57:49AM +0300, Timo Sirainen wrote:
On Thu, 2007-05-24 at 18:59 -0400, Adam McDougall wrote:
May 24 18:45:35 hostname dovecot: IMAP(username): fchown(/home/username/Maildir/dovecot/public/control/org/.mailfolder/dovecot-uidlist) failed: Operation not permitted
I'm not sure if you already figured this out, but these calls are used to change the file's group, not its owner.
Why would dovecot-shared affect files outside of the shared directory though?
Well.. Dovecot doesn't know if you want to have the control or index files shared. If they were shared, you'd want to preserve the group +mode.
Okay, I can see why you could want it. But it seems some flexibility is needed from the dovecot-shared behavior to match the flexibility of having control and index in seperate locations from the mailbox, since some mail environments would operationally (unwanted behavior) and/or technically (corruption potential) prevent the index and/or control from being shared.
Originally I was planning on removing the whole dovecot-shared file, but perhaps it needs to be there anyway. Inside it could be some settings that tell Dovecot how you want to preserve the group/mode. Maybe something like:
group = xyz # dovecot-shared file's group if not specified #group = # empty == no change mode = 0660 # dovecot-shared file's mode if not specified private_flags = \Seen \Flagged # Default is \Seen index_group = index_mode = control_group = control_mode =
That would be an excellent feature, especially being able to control the private_flags, which I previously only had limited control over using file permissions and the acl plugin. But, I think the current behavior of dovecot-shared should hopefully suffice for my situation (after the private flags patch) as long as it doesn't cause any other unexpected behavior :)