[Dovecot] 1.0-test22 - maildir fixed?
Well, remember when I said:
Here you go, maildir syncing problems finally fixed (I hope). Well, except there's this "new-dir-only syncing" optimization which I'm not really sure if it works as it should.
Just before I found the expunge bug in index, I was trying to fix the new-dir-only syncing because the code looked wrong. Then I figured out the indexing problem and thought maybe this one wasn't broken after all, and then forgot about it.
Finally after lots of debugging, I came to same conclusion again. The code was wrong, and cause of the remaining "Maildir sync: UID < next_uid (312 < 3)" errors.
So, please try and see if you still can break this release. Other changes include some crashfixes for cache file and fix for mbox which kept constantly rewriting headers for \recent messages if we had selected the mailbox as read-only (EXAMINE, STATUS).
Timo Sirainen wrote:
So, please try and see if you still can break this release.
I have done some stress testing with Maildir, POP3 and IMAP today and this release looks very promising, UID errors are gone. I can see some timeouts of transaction log locks but those seem to be a pretty rare.
If only Dovecot would support Qpopper X-UIDL header I'd replace Qpopper with Dovecot on my personal mail server rigth away :-)
On Wed, 2004-06-23 at 18:50, Tomi Hakala wrote:
If only Dovecot would support Qpopper X-UIDL header I'd replace Qpopper with Dovecot on my personal mail server rigth away :-)
Well, I added most of the code required to do it, but then got a bit stuck at trying to save the X-UIDL into cache file. Normally we don't wait locks for cache file, if we didn't get it immediately we just don't update it. X-UIDL would be pretty much required to be stored in it to get reasonable performance, so we'd have to wait for the lock. But that's yet another thing to consider when making sure that deadlocks don't happen. I think I'll implement it at the same time I fix the already existing mbox deadlock bug.
This change also makes it possible to replace pop3-uidl-uwimap.patch with a plugin. But overriding methods in struct mail is pretty difficult now, I'd have to figure out some easier way..
I spoke a bit too fast in my last message ;)
I'm having a bunch of these logs after a few hours (test22):
Jun 24 07:55:55 aster dovecot: IMAP(nico): open() failed with index file /home/nico/mail/.imap/Curie-perso/dovecot.index: Too many open files Jun 24 07:55:55 aster dovecot: IMAP(nico): open() failed with index file /home/nico/mail/Crans/.imap/Moderateurs/dovecot.index: Too many open files Jun 24 07:55:55 aster dovecot: IMAP(nico): open() failed with index file /home/nico/mail/Debian/.imap/debian-news/dovecot.index: Too many open files Jun 24 07:55:55 aster dovecot: IMAP(nico): open() failed with index file /home/nico/mail/Debian/.imap/debian-user-french/dovecot.index: Too many open files
...
There's a lot like these for all of my imap folders. Is there a way to fix it ?
Thanx
Nico La foi du savant ne ressemble pas à celle que les orthodoxes puisent dans le besoin de certitude. Il ne faut pas croire que l'amour de la vérité se confondent avec celui de la certitude... Non, la foi du savant ressemblerait plutôt à la foi inquiète de l'hérétique, à celle qui cherche toujours et n'est jamais satisfaite. -+- Henri Poincaré -+-
Nicolas STRANSKY wrote:
Jun 24 07:55:55 aster dovecot: IMAP(nico): open() failed with index file /home/nico/mail/Debian/.imap/debian-user-french/dovecot.index: Too many open files
...
There's a lot like these for all of my imap folders. Is there a way to fix it ?
See how many open files your system supports, with a kernel 2.4.26 and 256M memory default is 26208 open files.
# cat /proc/sys/fs/file-max 26208
You can double the value pretty safely
echo "65535" > /proc/sys/fs/file-max
To have new value set on a boot put it in a /etc/sysctl.conf like
fs.file-max=65535
Tomi Hakala wrote:
See how many open files your system supports, with a kernel 2.4.26 and 256M memory default is 26208 open files.
# cat /proc/sys/fs/file-max 26208
The value of file-max on my system is already 51159 (kernel 2.6.7, 512MB memory). But the interesting thing is that there are not that much open files, and I didn't have this problem with previous dovecot release.
Nicolas STRANSKY wrote:
The value of file-max on my system is already 51159 (kernel 2.6.7, 512MB memory). But the interesting thing is that there are not that much open files, and I didn't have this problem with previous dovecot release.
I also notice that thunderbird 0.7 fails to copy a message to the "Sent" folder with Dovecot 1.0 test22. More generaly, I have problems moving or copying messages from somewhere out of the existing imap folders (such as a message that has just been sent), to an imap folder. I'm pretty sure it's not a thunderbird problem because it appeared when I installed Dovecot 1.0 test22. THunderbird just says it "failed", and I see no particular logs on the server.
Le 06/24/2004 04:21 PM, Nicolas STRANSKY a écrit :
I also notice that thunderbird 0.7 fails to copy a message to the "Sent" folder with Dovecot 1.0 test22. More generaly, I have problems moving or copying messages from somewhere out of the existing imap folders (such as a message that has just been sent), to an imap folder. I'm pretty sure it's not a thunderbird problem because it appeared when I installed Dovecot 1.0 test22. THunderbird just says it "failed", and I see no particular logs on the server.
Reverting to Dovecot 0.99.10.6 solves this issue... So what could cause this in Dovecot 1.0-test ?
Nicolas STRANSKY wrote:
Le 06/24/2004 04:21 PM, Nicolas STRANSKY a écrit :
I also notice that thunderbird 0.7 fails to copy a message to the "Sent" folder with Dovecot 1.0 test22. More generaly, I have problems moving or copying messages from somewhere out of the existing imap folders (such as a message that has just been sent), to an imap folder. I'm pretty sure it's not a thunderbird problem because it appeared when I installed Dovecot 1.0 test22. THunderbird just says it "failed", and I see no particular logs on the server.
Same here with test23 amd Mozilla 1.6 (NetBSD, Linux) - it sends the mail, but hangs a while trying to store a copy in the sent-folder and then times out. Doesn't happen with Sylpheed nor Eudora.
hauke
On Thu, 1 Jul 2004 06:03 pm, Hauke Fath wrote:
Nicolas STRANSKY wrote:
Le 06/24/2004 04:21 PM, Nicolas STRANSKY a écrit :
I also notice that thunderbird 0.7 fails to copy a message to the "Sent" folder with Dovecot 1.0 test22. More generaly, I have problems moving or copying messages from somewhere out of the existing imap folders (such as a message that has just been sent), to an imap folder. I'm pretty sure it's not a thunderbird problem because it appeared when I installed Dovecot 1.0 test22. THunderbird just says it "failed", and I see no particular logs on the server.
Same here with test23 amd Mozilla 1.6 (NetBSD, Linux) - it sends the mail, but hangs a while trying to store a copy in the sent-folder and then times out. Doesn't happen with Sylpheed nor Eudora.
hauke
I saw this when I originaly tried Thunderbird 0.5 on Dovecot 0.99.10.4... haven't seen it on any other clients, including later version of Thunderbird.
On Thu, 01 Jul 2004 10:03:27 +0200 Hauke Fath wrote:
Same here with test23 amd Mozilla 1.6 (NetBSD, Linux) - it sends the mail, but hangs a while trying to store a copy in the sent-folder and then times out. Doesn't happen with Sylpheed nor Eudora.
Replying to myself - my users report they get locked out, and the logs show me
Jul 1 10:00:46 bounce dovecot: IMAP(cbrown): file mbox-sync-rewrite.c: line 325 (mbox_sync_read_and_move): assertion failed: (need_space == -mails[idx].space) Jul 1 10:00:46 bounce dovecot: child 1992 (imap) killed with signal 6
(repeatedly; user action was a bulk move from mailbox to mailbox, with the /home file-system having 20G free)
and then
Jul 1 10:02:10 bounce dovecot: IMAP(brcic): file mail-transaction-log-view.c: line 122 (mail_transaction_log_view_set): assertion failed: (min_file_seq != max_file_seq || min_file_offse t <= max_file_offset) Jul 1 10:02:10 bounce dovecot: child 10098 (imap) killed with signal 6
and further
Jul 1 10:05:06 bounce dovecot: pipe() failed: Too many open files Jul 1 10:05:37 bounce last message repeated 312778 times Jul 1 10:05:58 bounce last message repeated 211646 times
and finally it dies. For the moment, I am back to 0.99.10.6.
hauke
On 1.7.2004, at 11:23, Hauke Fath wrote:
Jul 1 10:00:46 bounce dovecot: IMAP(cbrown): file mbox-sync-rewrite.c: line 325 (mbox_sync_read_and_move): assertion failed: (need_space == -mails[idx].space) Jul 1 10:00:46 bounce dovecot: child 1992 (imap) killed with signal 6
(repeatedly; user action was a bulk move from mailbox to mailbox, with the /home file-system having 20G free)
Thanks, this is most likely fixed now. Either one of the mboxes probably had "folder internal data" message generated by UW-IMAP?
and then
Jul 1 10:02:10 bounce dovecot: IMAP(brcic): file mail-transaction-log-view.c: line 122 (mail_transaction_log_view_set): assertion failed: (min_file_seq != max_file_seq || min_file_offse t <= max_file_offset) Jul 1 10:02:10 bounce dovecot: child 10098 (imap) killed with signal 6
This usually happens as a result of some other bug. Possibly because of the assert. I'll fix the whole transaction log error handling some day.
and further
Jul 1 10:05:06 bounce dovecot: pipe() failed: Too many open files Jul 1 10:05:37 bounce last message repeated 312778 times Jul 1 10:05:58 bounce last message repeated 211646 times
This is more annoying to debug. I guess there's a leak somewhere, but I haven't yet found it.. Unless you had set some fd limits before starting dovecot?
Am 02.07.2004 um 15:14 Uhr +0300 schrieb Timo Sirainen:
Jul 1 10:00:46 bounce dovecot: IMAP(cbrown): file mbox-sync-rewrite.c: line 325 (mbox_sync_read_and_move): assertion failed: (need_space == -mails[idx].space) Jul 1 10:00:46 bounce dovecot: child 1992 (imap) killed with signal 6
(repeatedly; user action was a bulk move from mailbox to mailbox, with the /home file-system having 20G free)
Thanks, this is most likely fixed now.
Cool.
Either one of the mboxes probably had "folder internal data" message generated by UW-IMAP?
May well be - all the mail was migrated from a uw-imap server a few weeks ago. I cleaned my mailboxes out, but others most likely did not.
Jul 1 10:05:06 bounce dovecot: pipe() failed: Too many open files Jul 1 10:05:37 bounce last message repeated 312778 times Jul 1 10:05:58 bounce last message repeated 211646 times
This is more annoying to debug. I guess there's a leak somewhere, but I haven't yet found it.. Unless you had set some fd limits before starting dovecot?
Not that I know of...
hauke
On 1.7.2004, at 10:36, Nicolas STRANSKY wrote:
Le 06/24/2004 04:21 PM, Nicolas STRANSKY a écrit :
I also notice that thunderbird 0.7 fails to copy a message to the "Sent" folder with Dovecot 1.0 test22. More generaly, I have problems moving or copying messages from somewhere out of the existing imap folders (such as a message that has just been sent), to an imap folder. I'm pretty sure it's not a thunderbird problem because it appeared when I installed Dovecot 1.0 test22. THunderbird just says it "failed", and I see no particular logs on the server.
Reverting to Dovecot 0.99.10.6 solves this issue... So what could cause this in Dovecot 1.0-test ?
This was also with mboxes which had "folder internal data" messages? If so, fixed.
Nicolas STRANSKY wrote:
I also notice that thunderbird 0.7 fails to copy a message to the "Sent" folder with Dovecot 1.0 test22.
I have seen this many times on UW-IMAP with mboxes, but not once with Dovecot. To be sure I just tested Netscape 7.1 and Thunderbird with Dovecot 1.0-test23 and copying message to Sent folder worked every time.
This is with mboxes, I'll have to try and see if Maildirs behave differently.
On 2004-06-24 14:55:42 +0200, Nicolas STRANSKY wrote:
See how many open files your system supports, with a kernel 2.4.26 and 256M memory default is 26208 open files.
# cat /proc/sys/fs/file-max 26208
The value of file-max on my system is already 51159 (kernel 2.6.7, 512MB memory). But the interesting thing is that there are not that much open files, and I didn't have this problem with previous dovecot release.
maybe check for per user limits via pam? e.g /etc/security/limits.conf
darix
On Thu, 2004-06-24 at 17:24, Marcus Rueckert wrote:
On 2004-06-24 14:55:42 +0200, Nicolas STRANSKY wrote:
See how many open files your system supports, with a kernel 2.4.26 and 256M memory default is 26208 open files.
# cat /proc/sys/fs/file-max 26208
The value of file-max on my system is already 51159 (kernel 2.6.7, 512MB memory). But the interesting thing is that there are not that much open files, and I didn't have this problem with previous dovecot release.
maybe check for per user limits via pam? e.g /etc/security/limits.conf
Nah, this most likely happens because Dovecot doesn't close some (index?) files. I'll debug it later.
On Thu, 2004-06-24 at 09:02, Nicolas STRANSKY wrote:
I spoke a bit too fast in my last message ;)
I'm having a bunch of these logs after a few hours (test22):
Jun 24 07:55:55 aster dovecot: IMAP(nico): open() failed with index file /home/nico/mail/.imap/Curie-perso/dovecot.index: Too many open files Jun 24 07:55:55 aster dovecot: IMAP(nico): open() failed with index file /home/nico/mail/Crans/.imap/Moderateurs/dovecot.index: Too many open files Jun 24 07:55:55 aster dovecot: IMAP(nico): open() failed with index file /home/nico/mail/Debian/.imap/debian-news/dovecot.index: Too many open files Jun 24 07:55:55 aster dovecot: IMAP(nico): open() failed with index file /home/nico/mail/Debian/.imap/debian-user-french/dovecot.index: Too many open files
...
There's a lot like these for all of my imap folders. Is there a way to fix it ?
I found some leaks from transaction log file handling, but they should have been pretty rare. Could you send the output of ls -l /proc/pid/fd/ when it shows lots of same files? pid would be the PID of imap process.
On Wed, Jun 23, 2004 at 09:16:32AM +0300, Timo Sirainen wrote:
Well, remember when I said:
Here you go, maildir syncing problems finally fixed (I hope). Well, except there's this "new-dir-only syncing" optimization which I'm not really sure if it works as it should.
Just before I found the expunge bug in index, I was trying to fix the new-dir-only syncing because the code looked wrong. Then I figured out the indexing problem and thought maybe this one wasn't broken after all, and then forgot about it.
Finally after lots of debugging, I came to same conclusion again. The code was wrong, and cause of the remaining "Maildir sync: UID < next_uid (312 < 3)" errors.
So, please try and see if you still can break this release. Other changes include some crashfixes for cache file and fix for mbox which kept constantly rewriting headers for \recent messages if we had selected the mailbox as read-only (EXAMINE, STATUS).
Sorry, still getting:
sp dovecot: IMAP(moe): Maildir /home/moe/Maildir/.INBOX.zp sync: UID inserted in the middle of mailbox (1515 > 1514, file = msg.QNsy:2,)
and:
sp dovecot: IMAP(moe): Corrupted index cache file /home/moe/Maildir/.INBOX.zp/dovecot.index.cache: indexid changed
On Thu, 2004-06-24 at 21:32, Moe Wibble wrote:
Sorry, still getting:
sp dovecot: IMAP(moe): Maildir /home/moe/Maildir/.INBOX.zp sync: UID inserted in the middle of mailbox (1515 > 1514, file = msg.QNsy:2,)
Are you sure the maildir filename is unique and has never existed before? If "msg.QNsy" is the real name, it doesn't conform to maildir spec, although Dovecot doesn't really care about that. But if QNsy is eg. inode number, this could easily happen just because inode numbers are reused and you don't have any kind of timestamp in the file name.
Older Dovecots and probably most other maildir clients don't complain about reappearing files, but I think that may cause some (rare) hidden problems.
If they really are unique, it would be helpful if you could run a debugging patch and send all the output to me. It generates /tmp/dovecot.* files with tons of debugging data.
On Mon, Jun 28, 2004 at 12:39:08PM +0300, Timo Sirainen wrote:
On Thu, 2004-06-24 at 21:32, Moe Wibble wrote:
Sorry, still getting:
sp dovecot: IMAP(moe): Maildir /home/moe/Maildir/.INBOX.zp sync: UID inserted in the middle of mailbox (1515 > 1514, file = msg.QNsy:2,)
Are you sure the maildir filename is unique and has never existed before? If "msg.QNsy" is the real name, it doesn't conform to maildir spec, although Dovecot doesn't really care about that. But if QNsy is eg. inode number, this could easily happen just because inode numbers are reused and you don't have any kind of timestamp in the file name.
Nope, I'm not sure. The only program delivering to my maildirs is procmail, tho. Seems like procmail creates these kind of filenames, should I file a bug?
Older Dovecots and probably most other maildir clients don't complain about reappearing files, but I think that may cause some (rare) hidden problems.
If the bugs are gone for other people then that's most likely the cause. Strange enough that procmail doesn't write properly to Maildirs.
If they really are unique, it would be helpful if you could run a debugging patch and send all the output to me. It generates /tmp/dovecot.* files with tons of debugging data.
I'm not sure whether they're unique but since they're only 4 digits I suppose they're at best some Very Cheap Imitation of unique... I guess it's time to find a better mailfilter than procmail.
Gonna try that later if switching to a filter that writes _real_ Maildir didn't help.
Any suggestions on what to use? It should run from dot-qmail..
greets
On Jun 28, 2004, at 4:57 PM, Moe Wibble wrote:
I'm not sure whether they're unique but since they're only 4 digits I suppose they're at best some Very Cheap Imitation of unique... I guess it's time to find a better mailfilter than procmail.
Gonna try that later if switching to a filter that writes _real_ Maildir didn't help.
At home I run procmail from sendmail (as the local mailer) and it generates files like:
1085555933.58805_0.hostname
which seems to be a timestamp, the PID of procmail with an addition and a hostname.
My procmail version is built from ports on freebsd 5.1 and is: "procmail v3.22 2001/09/10".
Kind regards,
Maikel Verheijen
On Mon, Jun 28, 2004 at 05:32:58PM +0200, Maikel Verheijen wrote:
On Jun 28, 2004, at 4:57 PM, Moe Wibble wrote:
I'm not sure whether they're unique but since they're only 4 digits I suppose they're at best some Very Cheap Imitation of unique... I guess it's time to find a better mailfilter than procmail.
Gonna try that later if switching to a filter that writes _real_ Maildir didn't help.
At home I run procmail from sendmail (as the local mailer) and it generates files like:
1085555933.58805_0.hostname
which seems to be a timestamp, the PID of procmail with an addition and a hostname.
My procmail version is built from ports on freebsd 5.1 and is: "procmail v3.22 2001/09/10".
Ah, interesting. I'm running the "same" version but from debian:
procmail v3.22 2001/09/10 procmail_3.22-9_i386.deb
Your message (the one I am replying to) was stored as: msg.qBs4
Seems the BSD port has some patch applied that the debian version hasn't. I'm gonna file a bug report to the package maintainer.
greets
On Mon, Jun 28, 2004 at 05:47:24PM +0200, Moe Wibble wrote:
On Mon, Jun 28, 2004 at 05:32:58PM +0200, Maikel Verheijen wrote:
On Jun 28, 2004, at 4:57 PM, Moe Wibble wrote:
I'm not sure whether they're unique but since they're only 4 digits I suppose they're at best some Very Cheap Imitation of unique... I guess it's time to find a better mailfilter than procmail.
Gonna try that later if switching to a filter that writes _real_ Maildir didn't help.
At home I run procmail from sendmail (as the local mailer) and it generates files like:
1085555933.58805_0.hostname
which seems to be a timestamp, the PID of procmail with an addition and a hostname.
My procmail version is built from ports on freebsd 5.1 and is: "procmail v3.22 2001/09/10".
Ah, interesting. I'm running the "same" version but from debian:
procmail v3.22 2001/09/10 procmail_3.22-9_i386.deb
Your message (the one I am replying to) was stored as: msg.qBs4
Seems the BSD port has some patch applied that the debian version hasn't. I'm gonna file a bug report to the package maintainer.
Problem solved. It was my fault... The pkg-maintainer Santiago instantly replied to my bug report and enlightened me about my broken procmailrc. I was missing the slashes after the Maildir paths so procmail didn't treat them as Maildirs but as.. well, dirs that don't require unique names.
I've corrected my mistake and gonna give that test22 another shot. Sorry for causing confusion!
best regards
On 28.6.2004, at 22:57, Moe Wibble wrote:
Problem solved. It was my fault... The pkg-maintainer Santiago instantly replied to my bug report and enlightened me about my broken procmailrc. I was missing the slashes after the Maildir paths so procmail didn't treat them as Maildirs but as.. well, dirs that don't require unique names.
Perhaps Dovecot should require at least minimal compliance from maildir filenames so problem like these wouldn't happen. IIRC Courier requires that filename starts with digit, otherwise it isn't touched.
Anyone have opinions either way?
One reason why I haven't added any checks is because while testing I often create filenames such as "foo", "foo2", etc. Might take a while to start remembering that digit is required as first character.
On Jun 28, 2004, at 10:12 PM, Timo Sirainen wrote:
On 28.6.2004, at 22:57, Moe Wibble wrote:
Perhaps Dovecot should require at least minimal compliance from maildir filenames so problem like these wouldn't happen. IIRC Courier requires that filename starts with digit, otherwise it isn't touched.
Anyone have opinions either way?
Why not hold on to the maildir standard and enforce that? Maybe complain about invalid mail-files?
http://cr.yp.to/proto/maildir.html contains the following passage: Okay, so you're writing messages. A unique name has three pieces, separated by dots. On the left is the result of time() or the second counter from gettimeofday(). On the right is the result of gethostname(). (To deal with invalid host names, replace / with \057 and : with \072.) In the middle is a delivery identifier, discussed below.
Which states it should contain 3 dots, the left portion should be a timestamp, the middle "an identifier" and the right hand side a hostname. This means you can check if it has a) 2 dots (3 pieces) and starts with a valid timestamp?
One reason why I haven't added any checks is because while testing I often create filenames such as "foo", "foo2", etc. Might take a while to start remembering that digit is required as first character.
This is indeed a pain if you don't follow the maildir standard. However
it is pretty easy to generate a "custom" mailfile-name creator :)
eg: printf "%d.%d.%s\n" date +%s "$$" hostname -s
Kind regards,
Maikel Verheijen Ladot Nederland BV.
On Tue, 2004-06-29 at 15:02, Maikel Verheijen wrote:
Perhaps Dovecot should require at least minimal compliance from maildir filenames so problem like these wouldn't happen. IIRC Courier requires that filename starts with digit, otherwise it isn't touched.
Anyone have opinions either way?
Why not hold on to the maildir standard and enforce that?
Well, it seems a bit bad for me to constantly waste CPU for things that aren't needed for anything else than catching other people's configuration mistakes.
Checking the first character is a simple check and I could live with that, fully checking the filename is nearing bloat.
Maybe complain about invalid mail-files?
Probably, yes..
Why not hold on to the maildir standard and enforce that?
Agreed. Courier is wrong.
From: http://cr.yp.to/proto/maildir.html
"A unique name can be anything that doesn't contain a colon (or slash) and doesn't start with a dot. Do not try to extract information from unique names."
On 29.6.2004, at 21:24, Geo Carncross wrote:
Why not hold on to the maildir standard and enforce that?
Agreed. Courier is wrong.
Actually now that I looked it doesn't check anything. Guess I remembered wrong.
From: http://cr.yp.to/proto/maildir.html
"A unique name can be anything that doesn't contain a colon (or slash) and doesn't start with a dot. Do not try to extract information from unique names."
Right.. I should read that page every time before I think about doing some changes :)
On Wed, Jun 23, 2004 at 09:16:32AM +0300, Timo Sirainen wrote:
Well, remember when I said:
Here you go, maildir syncing problems finally fixed (I hope). Well, except there's this "new-dir-only syncing" optimization which I'm not really sure if it works as it should.
While doing some test with 1.0-test22 I've found one strange bug which seems to be related to the 'FOLDER INTERNAL DATA' mail that will be in inserted by uw-imap.
To reproduce:
- stop dovecot, start uw-imap
- create a new folder and cp some mails into this new folder
- stop uw-imap, start dovecot
- select the new created folder
Dovecot v1.0-test22 starting up imap-login: Login: juergen [192.168.0.1] IMAP(juergen): file mail-index-transaction.c: line 147 (mail_index_transaction_lookup): assertion failed: (seq >= t->first_new_seq && seq <= t->last_new_seq) child 4432 (imap) killed with signal 6
After reselecting this folder with my client (mutt) I can see sometimes either one additional mail at the bottom or even the first mail doubled ?
Sorry, but some other errors, which may be related:
IMAP(juergen): mbox sync: UID inserted in the middle of mailbox /home/juergen/Mail/_spam (241 > 240) IMAP(juergen): file mail-index-view.c: line 176 (_view_lookup_full): assertion failed: (seq > 0 && seq <= mail_index_view_get_message_count(view)) child 2891 (imap) killed with signal 6
and
IMAP(juergen): file mbox-sync-rewrite.c: line 320 (mbox_sync_read_and_move): assertion failed: (need_space == -mails[idx].space) child 2899 (imap) killed with signal 6
Greetings Juergen
On Mon, 2004-06-28 at 17:40, Juergen Daubert wrote:
While doing some test with 1.0-test22 I've found one strange bug which seems to be related to the 'FOLDER INTERNAL DATA' mail that will be in inserted by uw-imap.
Thanks, fixed.
After reselecting this folder with my client (mutt) I can see sometimes either one additional mail at the bottom or even the first mail doubled ?
I guess it could have generated many kinds of errors.
Sorry, but some other errors, which may be related:
..
Most likely, yes. I also fixed some other mbox problems which might have caused them.
CVS currently has somewhat broken cache file code, I'll try to fix it tomorrow and build test23. I think I figured out some pretty nice rules how to figure out what to keep in cache.
participants (11)
-
Curtis Maloney
-
Geo Carncross
-
Hauke Fath
-
Juergen.Daubert＠t-online.de
-
Maikel Verheijen
-
Marcus Rueckert
-
Moe Wibble
-
Nicolas STRANSKY
-
Nicolas STRANSKY
-
Timo Sirainen
-
Tomi Hakala