first, thx for --with-storages=maildir
second, there is a problem when user exceed their quota
< status INBOX (messages)
NO Internal error [2003-05-06 15:35:56]
in logfile: imap(user): Can't create directory /var/mail/user/.INBOX: Disk quota exceeded
'user' is not able to get list of messages and delete some of them :(
third,
in logfile:
imap(user2): maildir flags update: rename(/var/mail/user2/cur/1049405360.18375_0.asd, /var/mail/user2/cur/1049405360.18375_0.asd:2,T) failed: Disk quota exceeded
is there any way to rename files when quota exceed?
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..
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 <dovecot.procontrol.fi> List-Unsubscribe: <http://procontrol.fi/cgi-bin/mailman/listinfo/dovecot>, <mailto:dovecot-request@procontrol.fi?subject=unsubscribe> List-Archive: <http://procontrol.fi/pipermail/dovecot> List-Post: <mailto:dovecot@procontrol.fi> List-Help: <mailto:dovecot-request@procontrol.fi?subject=help> List-Subscribe: <http://procontrol.fi/cgi-bin/mailman/listinfo/dovecot>, <mailto:dovecot-request@procontrol.fi?subject=subscribe> Sender: dovecot-bounces@procontrol.fi Errors-To: dovecot-bounces@procontrol.fi
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
participants (3)
-
Mike Machado
-
Sebastian Pachuta
-
Timo Sirainen