Believe me, over quota conditions is a major source of ISP support headaches. Entire systems have been designed around trying to manage this very issue.
I think doing something special under this unique condition to at least allow some messages to be deleted is acceptable as long as it does not corrupt mail, even if it includes forcing a client logout.
As a side thought, couldn't you delete the message from the mailbox, THEN update the UID list, because at that point you would be able to write to the file?
On Tue, 2003-05-06 at 19:56, Timo Sirainen wrote:
On Tue, 2003-05-06 at 16:50, Sebastian Pachuta wrote:
second, there is a problem when user exceed their quota
Yes, there's several problems. Biggest one is what to do if we can't update dovecot-uidlist file.
If we continued normally but without storing the UIDs permanently, then expunged some messages, logged out and logged in again, the UIDs are different from last time and that breaks client's cache.
If we just overwrote next-UID field in dovecot-uidlist we'd get new UIDs next time which is fine, except if client selects the mailbox multiple times it gets different UIDs for the messages. That probably breaks some clients (OE I think).
One kludgy solution is to overwrite next-UID field only when messages are expunged and then force all clients that have selected the mailbox to log out.
Overwriting next-UID isn't too safe either since readers don't do any kind of locking for the file, but I'd hope writing 1-10 bytes is usually atomic? Well, we could use fcntl() locking in out-of-diskspace conditions but I'm not sure if it's worth it..
Mike Machado mike@innercite.com InnerCite Inc. Engineering Director / CTO
Return-Path: dovecot-bounces@procontrol.fi
Received: from danu.procontrol.fi (localhost [127.0.0.1])
by danu.procontrol.fi (Postfix) with ESMTP
id 5980E239A8; Mon, 12 May 2003 17:56:53 +0300 (EEST)
X-Original-To: dovecot@procontrol.fi
Delivered-To: dovecot@procontrol.fi
Received: from nssg.mitel.com (mail.e-smith.com [216.191.234.126])
by danu.procontrol.fi (Postfix) with SMTP id 57BCC238D1
for dovecot@procontrol.fi; Mon, 12 May 2003 17:56:52 +0300 (EEST)
Received: (qmail 21878 invoked by uid 404); 12 May 2003 14:56:51 -0000
Received: from charlieb-dovecot@e-smith.com by tripe.nssg.mitel.com with
qmail-scanner; 12 May 2003 10:56:50 -0000
Received: from allspice-core.nssg.mitel.com (HELO e-smith.com) (10.33.16.12)
by tripe.nssg.mitel.com (10.33.17.11) with SMTP; 12 May 2003 14:56:50 -0000
Received: (qmail 11560 invoked from network); 12 May 2003 14:56:50 -0000
Received: from vegemite.nssg.mitel.com (10.33.15.70)
by allspice.nssg.mitel.com with QMQP; 12 May 2003 14:56:50 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
by localhost with SMTP; 12 May 2003 15:01:14 -0000
Date: Mon, 12 May 2003 11:01:14 -0400 (EDT)
From: Charlie Brady charlieb-dovecot@e-smith.com
X-X-Sender: charlieb@vegemite.nssg.mitel.com
To: Timo Sirainen tss@iki.fi
Subject: Re: [dovecot] Re: Design thought - Retention of reworked mbox files
In-Reply-To: 1052701549.5227.415.camel@hurina
Message-ID: Pine.LNX.4.44.0305121100120.18840-100000@vegemite.nssg.mitel.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: dovecot@procontrol.fi
X-BeenThere: dovecot@procontrol.fi
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Dovecot Mailing List
On 12 May 2003, Timo Sirainen wrote:
On Mon, 2003-05-12 at 02:05, Tim Hunt wrote:
Would it be possible to keep a backup copy of an mbox mail file any time it needs to be substantionally rebuilt - for an example before an expunge. This behaviour could be controlled by the config file, since it would most likely only be used in development and testing environments.
If it's only for debugging, I guess I could then just save a copy of it.
Presumably the other reason you'd want it would be for mailbox integrity. But if you are concerned about that, you'd be using maildir, wouldn't you?
-- Charlie