[Dovecot] 1.0.rc10 released
http://dovecot.org/releases/dovecot-1.0.rc10.tar.gz http://dovecot.org/releases/dovecot-1.0.rc10.tar.gz.sig
I've finally read all the mails in the mailing list and in my INBOX. If I haven't replied to some of your mail, please resend it.
Remember that since 1.0.rc9 release dovecot.index.cache files will get rebuilt in 64bit systems, and it's probably better to delete them manually so you don't get errors in log files.
There are only a couple of issues left in my v1.0-TODO list:
- Master process appears to be leaking log fds with kqueue. Could someone again give me access to a system where this happens?
- Login process problems. How well does it work now? Hopefully well enough that v1.0 could be released.
- LDAP authentication is leaking memory? Can anyone confirm this? Even better, can someone figure out what exactly is leaking? :) Not a v1.0 blocker though.
I think v1.0 will be released once no-one has reported any major problems for a Dovecot release in 2-4 weeks. I think login process handling is the only potentially major problem left.
There are a few patches from people that I haven't forgotten, but I've decided not to put them into v1.0 anymore:
- Filesystem quota group. I don't think it's that important feature, and it might break something.
- HFS+ hardlink avoiding
- Managesieve
- vmailmgr support
And finally the changes in this release:
* When matching allowed_nets IPs, convert IPv6-mapped-IPv4 addresses
to actual IPv4 addresses first.
+ IMAP: Try to avoid sending duplicate/useless message flag updates
+ Added support for non-plaintext authentication for vpopmail if it
returns plaintext passwords. Based on patch by Remi Gacogne.
+ Added %D modified to return "sub.domain.org" as
"sub,dc=domain,dc=org" (for LDAP queries). Patch by Andrey Panin.
- rc9 broke cache files in 64bit systems
- deliver works now with mail_chroot
- auth cache didn't work properly with multiple passdbs
- Fixes to handling CRLF linefeeds in mboxes.
Timo Sirainen wrote:
Remember that since 1.0.rc9 release dovecot.index.cache files will get rebuilt in 64bit systems, and it's probably better to delete them manually so you don't get errors in log files.
Could someone tell me what would happen if I have dovecot running on both 64bit and 32bit machines with a common filesystem (NFS or replicated fs).
On 16.10.2006, at 9.45, Renaud Allard wrote:
Timo Sirainen wrote:
Remember that since 1.0.rc9 release dovecot.index.cache files will
get rebuilt in 64bit systems, and it's probably better to delete them manually so you don't get errors in log files.Could someone tell me what would happen if I have dovecot running on both 64bit and 32bit machines with a common filesystem (NFS or replicated fs).
This change was done exactly for that situation. With 1.0.rc9 you can
have both 32bit and 64bit machines accessing the same files without
problems. As long as you're not using both little-endian and big-
endian machines..
Mart Pirita wrote:
Tere.
Remember that since 1.0.rc9 release dovecot.index.cache files will get rebuilt in 64bit systems, and it's probably better to delete them
Any hint for good script to delete them from all users? And will this make any problems for users?
find /where/the/index/files/are/ -name dovecot.index*|xargs rm
cheers dirk
On Mon, Oct 16, 2006 at 10:31:23AM +0200, Dirk Essl wrote:
Mart Pirita wrote:
Any hint for good script to delete them from all users?
find /where/the/index/files/are/ -name dovecot.index*|xargs rm
Don't forget to escape the *.
find /path -name dovecot.index.\* | xargs rm
And will this make any problems for users?
No, they're just indexes. Dovecot will regenerate them for you.
Geert
Geert Hendrickx wrote:
On Mon, Oct 16, 2006 at 10:31:23AM +0200, Dirk Essl wrote:
Mart Pirita wrote:
Any hint for good script to delete them from all users? find /where/the/index/files/are/ -name dovecot.index*|xargs rm
Don't forget to escape the *.
find /path -name dovecot.index.\* | xargs rm
but if you do like you suggest, you will miss the 'dovecot.index' file
And will this make any problems for users?
No, they're just indexes. Dovecot will regenerate them for you.
Geert
just my two cents
dirk
On Mon, Oct 16, 2006 at 10:42:59AM +0200, Geert Hendrickx wrote:
On Mon, Oct 16, 2006 at 10:31:23AM +0200, Dirk Essl wrote:
Mart Pirita wrote:
Any hint for good script to delete them from all users?
find /where/the/index/files/are/ -name dovecot.index*|xargs rm
Don't forget to escape the *.
find /path -name dovecot.index.\* | xargs rm
find /path -name 'dovecot.index.*' -exec rm {} \;
;)
Le 16 oct. 06 à 15:48, Petar Bogdanovic a écrit :
On Mon, Oct 16, 2006 at 10:42:59AM +0200, Geert Hendrickx wrote:
On Mon, Oct 16, 2006 at 10:31:23AM +0200, Dirk Essl wrote:
Mart Pirita wrote:
Any hint for good script to delete them from all users?
find /where/the/index/files/are/ -name dovecot.index*|xargs rm
Don't forget to escape the *.
find /path -name dovecot.index.\* | xargs rm
find /path -name 'dovecot.index.*' -exec rm {} \;
;)
find /path -name 'dovecot.index.*' -delete
;)
On Mon, Oct 16, 2006 at 04:54:14PM +0200, Remi Gacogne wrote:
Le 16 oct. 06 à 15:48, Petar Bogdanovic a écrit :
On Mon, Oct 16, 2006 at 10:42:59AM +0200, Geert Hendrickx wrote:
On Mon, Oct 16, 2006 at 10:31:23AM +0200, Dirk Essl wrote:
Mart Pirita wrote:
Any hint for good script to delete them from all users?
find /where/the/index/files/are/ -name dovecot.index*|xargs rm
Don't forget to escape the *.
find /path -name dovecot.index.\* | xargs rm
find /path -name 'dovecot.index.*' -exec rm {} \;
;)
find /path -name 'dovecot.index.*' -delete
`-delete' is not [1]portable. :]
$ find /path -name 'dovecot.index.*' -delete find: -delete: unknown option $ uname -mrs NetBSD 3.0 i386
[1] http://www.opengroup.org/onlinepubs/007908799/xcu/find.html
On Mon, 2006-10-16 at 15:48 +0200, Petar Bogdanovic wrote:
find /path -name dovecot.index.\* | xargs rm
find /path -name 'dovecot.index.*' -exec rm {} \;
The version with xargs is much more efficient on a large file store.
The second version forks a separate rm process for each file.
xargs forks the minimum number of rm processes required by the shell.
-- Ian
... and and even better version is:
find /path -name 'dovecot.index.*' -print0 | xargs -0 rm
Which doesn't do stupid things when you have mailboxes with spaces in their names.
P
On 10/16/06, Ian Mortimer <ian@physics.uq.edu.au> wrote:
On Mon, 2006-10-16 at 15:48 +0200, Petar Bogdanovic wrote:
find /path -name dovecot.index.\* | xargs rm
find /path -name 'dovecot.index.*' -exec rm {} \;
The version with xargs is much more efficient on a large file store. The second version forks a separate rm process for each file. xargs forks the minimum number of rm processes required by the shell.
-- Ian
On Mon, Oct 16, 2006 at 10:41:12PM -0700, Peter Abrahamsen wrote:
... and and even better version is:
find /path -name 'dovecot.index.*' -print0 | xargs -0 rm
Which doesn't do stupid things when you have mailboxes with spaces in their names.
On *BSD you can also use find -X which properly quotes the results.
Geert
On Tue, 17 Oct 2006, Noel Jones wrote:
On 10/17/06, Geert Hendrickx <ghen@telenet.be> wrote:
On *BSD you can also use find -X which properly quotes the results.
Nope, find -X skips files with strange characters. find -print0 | xargs -0 is the proper solution. $ man find
If you want to use a non-portable construct like "-print0", then there is a better way: use a "find" with built-in "xargs"-style functionality, like the "find" in recent versions of Solaris.
From the manual page:
-exec command
True if the executed command returns a zero value as
exit status. The end of command must be punctuated by
an escaped semicolon (;). A command argument { }
is replaced by the current path name. If the last
argument to -exec is { } and you specify + rather than
the semicolon (;), the command is invoked fewer times,
with { } replaced by groups of pathnames.
So, for example, you can use
find . -type f -name '*whatever*' -exec rm '{}' '+'
This avoids all the quoting issues as the files never even pass through the pipe.
- Logan
On Tue, 2006-10-17 at 13:25 -0500, Logan Shaw wrote:
On Tue, 17 Oct 2006, Noel Jones wrote:
On 10/17/06, Geert Hendrickx <ghen@telenet.be> wrote:
On *BSD you can also use find -X which properly quotes the results.
Nope, find -X skips files with strange characters. find -print0 | xargs -0 is the proper solution. $ man find
find . -type f -name '*whatever*' -exec rm '{}' '+'
Yes, but as already mentioned, this has the bad side effect of fork()ing one rm process per file, which is really inefficient.
It seems to me that if you want to delete files, you should use -delete, otherwise you should use -print0 | xargs -0 (if the command you're running works with multiple arguments), otherwise you should use -exec.
Richard
On Tue, 17 Oct 2006, Richard Laager wrote:
On Tue, 2006-10-17 at 13:25 -0500, Logan Shaw wrote:
On Tue, 17 Oct 2006, Noel Jones wrote:
On 10/17/06, Geert Hendrickx <ghen@telenet.be> wrote:
On *BSD you can also use find -X which properly quotes the results.
Nope, find -X skips files with strange characters. find -print0 | xargs -0 is the proper solution. $ man find
find . -type f -name '*whatever*' -exec rm '{}' '+'
Yes, but as already mentioned, this has the bad side effect of fork()ing one rm process per file, which is really inefficient.
I may not have highlighted the "+" clearly enough. It behaves differently than ";" does.
What I was saying is that if you are going to use a non-portable find feature (like "-print0"), Solaris 10 allows you to give "+" instead of ";" at the end. Then, as the Solaris 10 manual page says,
If the last argument to -exec is {} and you specify +
rather than the semicolon (;), the command is invoked
fewer times, with {} replaced by groups of pathnames.
So that is just as clean as the inefficient way, and more efficient than the "-print0 | xargs -0" way.
- Logan
On October 17, 2006 4:00:16 PM -0500 Logan Shaw <lshaw@emitinc.com> wrote:
What I was saying is that if you are going to use a non-portable find feature (like "-print0"), Solaris 10 allows you to give "+" instead of ";" at the end.
Actually, use of '+' is SUSv3 and so is the portable method. (There's no way Sun would implement a non-SUS option.)
-frank
On Tue, Oct 17, 2006 at 01:06:38PM -0500, Noel Jones wrote:
On 10/17/06, Geert Hendrickx <ghen@telenet.be> wrote:
On *BSD you can also use find -X which properly quotes the results.
Nope, find -X skips files with strange characters. find -print0 | xargs -0 is the proper solution. $ man find
-X The -X option is a modification to permit find to be safely used
in conjunction with xargs(1). If a file name contains any of the
delimiting characters used by xargs, a diagnostic message is dis-
played on standard error, and the file is skipped. The delimit-
ing characters include single (''') and double (
"'') quotes,
backslash (``\''), space, tab and newline characters. Alterna-
tively, the -print0 or -printx primaries can be used to format
the output in a way that xargs can accept.
Geert
On Tue, Oct 17, 2006 at 12:27:39PM +1000, Ian Mortimer wrote:
On Mon, 2006-10-16 at 15:48 +0200, Petar Bogdanovic wrote:
find /path -name dovecot.index.\* | xargs rm
find /path -name 'dovecot.index.*' -exec rm {} \;
The version with xargs is much more efficient on a large file store. The second version forks a separate rm process for each file.
xargs forks the minimum number of rm processes required by the shell.
No, it fires an rm process for each 5000 files (by default, change with find -n). I don't know which is more efficient though. Anyway, thinking about it will take more time than running either command. :-)
Geert
On Tue, Oct 17, 2006 at 10:44:07AM +0200, Geert Hendrickx wrote:
On Tue, Oct 17, 2006 at 12:27:39PM +1000, Ian Mortimer wrote:
On Mon, 2006-10-16 at 15:48 +0200, Petar Bogdanovic wrote:
find /path -name dovecot.index.\* | xargs rm
find /path -name 'dovecot.index.*' -exec rm {} \;
The version with xargs is much more efficient on a large file store. The second version forks a separate rm process for each file.
xargs forks the minimum number of rm processes required by the shell.No, it fires an rm process for each 5000 files (by default, change with find -n). I don't know which is more efficient though. Anyway, thinking about it will take more time than running either command. :-)
But it was a good opportunity to spot a nifty xargs-detail. ;)
BTW: Thanks for upgrading dovecot@pkgsrc!
On 16.10.2006, at 11.31, Dirk Essl wrote:
Mart Pirita wrote:
Tere.
Remember that since 1.0.rc9 release dovecot.index.cache files
will get rebuilt in 64bit systems, and it's probably better to delete themAny hint for good script to delete them from all users? And will this make any problems for users?
find /where/the/index/files/are/ -name dovecot.index*|xargs rm
It's enough to delete only dovecot.index.cache files. Deleting
everything will just slow down the system unneededly.
participants (13)
-
Dirk Essl
-
Frank Cusack
-
Geert Hendrickx
-
Ian Mortimer
-
Logan Shaw
-
Mart Pirita
-
Noel Jones
-
Petar Bogdanovic
-
Peter Abrahamsen
-
Remi Gacogne
-
Renaud Allard
-
Richard Laager
-
Timo Sirainen