http://dovecot.org/releases/dovecot-1.0.rc27.tar.gz http://dovecot.org/releases/dovecot-1.0.rc27.tar.gz.sig
A few new small features and lots of index/mbox fixes. I've been heavily stress testing this release, so I think it should be about perfect. :)
I think the only thing still missing from v1.0 is documentation. There are some unwritten pages in the wiki, and I still haven't bothered to write the wiki -> doc/*.txt conversion script. The script will probably be pretty easy, but writing the docs can take a while.
+ mbox and index file code handles silently out of quota/disk
space errors (maildir still has problems). They will give the user
a "Not enough disk space" error instead of flooding the log file.
+ Added fsync_disable setting.
+ mail-log plugin: Log the mailbox name, except if it's INBOX
+ dovecot-auth: Added a lot more debug logging to passdbs and userdbs
+ dovecot-auth: Added %c variable which expands to "secured" with
SSL/TLS/localhost.
+ dovecot-auth: Added %m variable which expands to auth mechanism name
- maildir++ quota: With ignore=box setting the quota was still updated
for the mailbox even though it was allowed to go over quota (but
quota recalculation ignored the box).
- Index file handling fixes
- mbox syncing fixes
- Wrong endianess index files still weren't silently rebuilt
- IMAP quota plugin: GETQUOTAROOT returned the mailbox name wrong the
namespace had a prefix or if its separator was non-default
- IMAP: If client was appending multiple messages with MULTIAPPEND
and LITERAL+ extensions and one of the appends failed, Dovecot
treated the rest of the mail data as IMAP commands.
- If mail was sent to client with sendfile() call, we could have
hanged the connection. This could happen only if mails were saved
with CR+LF linefeeds.Hi Timo, there is a small build problem in dovecot 1.0.rc27 on AIX: -------------------------------8<------------------------------------ source='mbox-file.c' object='mbox-file.o' libtool=no DEPDIR=.deps depmode=aix /bin/bash ../../../../depcomp /usr/local/src/mail/src/bin/dovecot-cc -qlanglvl=ansi -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../src/lib -I../../../../src/lib-mail -I../../../../src/lib-imap -I../../../../src/lib-index -I../../../../src/lib-storage -I../../../../src/lib-storage/index -DLDAP_DEPRECATED=1 -I/usr/local/include -I/usr/local/include -g -c mbox-file.c "mbox-sync-private.h", line 50.17: 1506-009 (S) Bit-field uid_broken must be of type signed int, unsigned int or int. "mbox-sync-private.h", line 51.17: 1506-009 (S) Bit-field expunged must be of type signed int, unsigned int or int. "mbox-sync-private.h", line 52.17: 1506-009 (S) Bit-field pseudo must be of type signed int, unsigned int or int. --------------------------------->8---------------------------------- It is that uid_broken, expunged, pseudo are defined as uint8_t:1 which is seemingly not allowed by xlc. Changing it to uint32_t:1 solves the problem. Do you think this is a appropriate way to fix this? I've attached a patch containing my changes. Regards, Ralf Becker Timo Sirainen schrieb am 13.03.2007 20:01:
http://dovecot.org/releases/dovecot-1.0.rc27.tar.gz http://dovecot.org/releases/dovecot-1.0.rc27.tar.gz.sig
A few new small features and lots of index/mbox fixes. I've been heavily stress testing this release, so I think it should be about perfect. :)
I think the only thing still missing from v1.0 is documentation. There are some unwritten pages in the wiki, and I still haven't bothered to write the wiki -> doc/*.txt conversion script. The script will probably be pretty easy, but writing the docs can take a while.
+ mbox and index file code handles silently out of quota/disk space errors (maildir still has problems). They will give the user a "Not enough disk space" error instead of flooding the log file. + Added fsync_disable setting. + mail-log plugin: Log the mailbox name, except if it's INBOX + dovecot-auth: Added a lot more debug logging to passdbs and userdbs + dovecot-auth: Added %c variable which expands to "secured" with SSL/TLS/localhost. + dovecot-auth: Added %m variable which expands to auth mechanism name - maildir++ quota: With ignore=box setting the quota was still updated for the mailbox even though it was allowed to go over quota (but quota recalculation ignored the box). - Index file handling fixes - mbox syncing fixes - Wrong endianess index files still weren't silently rebuilt - IMAP quota plugin: GETQUOTAROOT returned the mailbox name wrong the namespace had a prefix or if its separator was non-default - IMAP: If client was appending multiple messages with MULTIAPPEND and LITERAL+ extensions and one of the appends failed, Dovecot treated the rest of the mail data as IMAP commands. - If mail was sent to client with sendfile() call, we could have hanged the connection. This could happen only if mails were saved with CR+LF linefeeds.
-- ______________________________________________________________________ Dipl.-Inform. (FH) Ralf Becker Rechenzentrum (r/ft) der FH Trier (Network|Mail|Web|Firewall) University of applied sciences Administrator Schneidershof, D-54293 Trier Mail: beckerr@fh-trier.de Fon: +49 651 8103 499 WWW: http://www.fh-trier.de/~beckerr Fax: +49 651 8103 214 PGP: http://www.fh-trier.de/~beckerr/pgp ICQ: <available> ______________________________________________________________________ Wenn Gott gewollt haette, dass E-Mail in HTML geschrieben wuerden, endeten Gebete traditionell mit </amen>. (Tom Listen) --- ./dovecot-1.0.rc27/src/lib-storage/index/mbox/mbox-sync-private.h.org 2007-03-14 07:20:35.000000000 +0100 +++ ./dovecot-1.0.rc27/src/lib-storage/index/mbox/mbox-sync-private.h 2007-03-14 07:21:00.000000000 +0100 @@ -47,9 +47,9 @@ array_t ARRAY_DEFINE(keywords, unsigned int); uint8_t flags; - uint8_t uid_broken:1; - uint8_t expunged:1; - uint8_t pseudo:1; + uint32_t uid_broken:1; + uint32_t expunged:1; + uint32_t pseudo:1; uoff_t from_offset; uoff_t body_size;
On Wed, 2007-03-14 at 07:48 +0100, Ralf Becker wrote:
It is that uid_broken, expunged, pseudo are defined as uint8_t:1 which is seemingly not allowed by xlc. Changing it to uint32_t:1 solves the problem. Do you think this is a appropriate way to fix this?
Hmm. That's a bit annoying, because changing them to uint32_t:1 makes it eat more memory. Although I suppose 4 bytes per rewritten mail doesn't matter all that much..
Well, okay, I changed it back to "unsigned int" now: http://dovecot.org/list/dovecot-cvs/2007-March/008121.html
Ralf Becker wrote, On 14.3.2007 7:48: [...]
------------------------------------------------------------------------
--- ./dovecot-1.0.rc27/src/lib-storage/index/mbox/mbox-sync-private.h.org 2007-03-14 07:20:35.000000000 +0100 +++ ./dovecot-1.0.rc27/src/lib-storage/index/mbox/mbox-sync-private.h 2007-03-14 07:21:00.000000000 +0100 @@ -47,9 +47,9 @@ array_t ARRAY_DEFINE(keywords, unsigned int); uint8_t flags;
- uint8_t uid_broken:1; - uint8_t expunged:1; - uint8_t pseudo:1; + uint32_t uid_broken:1; + uint32_t expunged:1; + uint32_t pseudo:1; Maybe the whole chunk starting from uint8_t flags; could be like this instead:
uint32_t flags:8; uint32_t uid_broken:1; uint32_t expunged:1; uint32_t pseudo:1;
uoff_t from_offset; uoff_t body_size;
-- VH
On Sat, 2007-03-17 at 01:39 +0100, Václav Haisman wrote:
uint8_t flags;
- uint8_t uid_broken:1;
- uint8_t expunged:1;
- uint8_t pseudo:1;
- uint32_t uid_broken:1;
- uint32_t expunged:1;
- uint32_t pseudo:1; Maybe the whole chunk starting from uint8_t flags; could be like this instead:
uint32_t flags:8; uint32_t uid_broken:1; uint32_t expunged:1; uint32_t pseudo:1;
Right, I didn't think of that. But that feels a bit ugly :) I don't think it saves much memory anyway, so I'll keep it as uint8_t flags.
On Sun, 2007-03-18 at 17:51 +0200, Timo Sirainen wrote:
uint32_t flags:8; uint32_t uid_broken:1; uint32_t expunged:1; uint32_t pseudo:1;
Right, I didn't think of that. But that feels a bit ugly :) I don't think it saves much memory anyway, so I'll keep it as uint8_t flags.
Besides, on many platforms gcc generates horrendous code for bitfields.
johannes
On 18/03/2007 15:51, Timo Sirainen wrote:
On Sat, 2007-03-17 at 01:39 +0100, Václav Haisman wrote: [...]
uint32_t flags:8; uint32_t uid_broken:1; uint32_t expunged:1; uint32_t pseudo:1;
Right, I didn't think of that. But that feels a bit ugly :) I don't think it saves much memory anyway, so I'll keep it as uint8_t flags.
I may be a bit of a novice at this sort of thing, but if you want bitfields, does it matter what you say? In theory at least, unsigned int x:1; is all you need, it'll take one bit of storage, there's no point specifying the size of the thing you want truncated to one bit, what you're asking for is precisely one bit to be used as an unsigned integer. By saying e.g. uint8 x:1; you're specifying the size twice, and perhaps it's not a surprise if you get errors trying to compile it: which is it to be, 8 bits or 1?
Cheers,
John.
On Sun, 2007-03-18 at 19:01 +0000, John Robinson wrote:
On 18/03/2007 15:51, Timo Sirainen wrote:
On Sat, 2007-03-17 at 01:39 +0100, Václav Haisman wrote: [...]
uint32_t flags:8; uint32_t uid_broken:1; uint32_t expunged:1; uint32_t pseudo:1;
Right, I didn't think of that. But that feels a bit ugly :) I don't think it saves much memory anyway, so I'll keep it as uint8_t flags.
I may be a bit of a novice at this sort of thing, but if you want bitfields, does it matter what you say? In theory at least, unsigned int x:1; is all you need, it'll take one bit of storage, there's no point specifying the size of the thing you want truncated to one bit, what you're asking for is precisely one bit to be used as an unsigned integer. By saying e.g. uint8 x:1; you're specifying the size twice, and perhaps it's not a surprise if you get errors trying to compile it: which is it to be, 8 bits or 1?
Hmm. Looks like you're almost correct. I thought it worked so that if you had:
uint8_t foo; unsigned int bar:1;
That the bar would always allocate 32 bits more to the struct, but looks like it doesn't at least with gcc.
There is however one difference:
struct a { uint8_t f1; uint8_t f2:1; } struct b { uint8_t f1; unsigned int f2:1; }
sizeof(struct a) == 2 but sizeof(struct b) == 4
But this doesn't matter much. I don't think there's a single struct in Dovecot's code that doesn't contain 32bit or 64bit fields.
participants (5)
-
Johannes Berg
-
John Robinson
-
Ralf Becker
-
Timo Sirainen
-
Václav Haisman