Hiya
builds fine on BSD now (thanks)
Now I am getting index corruption again
May 30 03:11:53 snigger imap(bob): Corrupted binary tree file /home/bob/Mail/.INBOX/.imap.index.tree: UID to be inserted isn't higher than existing (1 <= 1)
and so on until the client hangs
test7 is stable here.
Also what are the correct permissions for /var/run/dovecot/login? I get a message about correcting the permissions every time I start dovecot
--Andrew
On Fri, 2003-05-30 at 05:27, Andrew Basterfield wrote:
Now I am getting index corruption again
May 30 03:11:53 snigger imap(bob): Corrupted binary tree file /home/bob/Mail/.INBOX/.imap.index.tree: UID to be inserted isn't higher than existing (1 <= 1)
Weird. Is this easily reproduceable? I tried for a while with my OpenBSD 3.3/x86, worked fine. Also I can't really even think of when the above error could happen unless something was totally messed up.
Also what are the correct permissions for /var/run/dovecot/login? I get a message about correcting the permissions every time I start dovecot
0750 mode, owned by root (or it uses geteuid() actually), group for login_user's primary group.
On 30 May 2003 13:24:51 +0300, Timo Sirainen tss@iki.fi wrote:
On Fri, 2003-05-30 at 05:27, Andrew Basterfield wrote:
Now I am getting index corruption again
May 30 03:11:53 snigger imap(bob): Corrupted binary tree file /home/bob/Mail/.INBOX/.imap.index.tree: UID to be inserted isn't higher than existing (1 <= 1)
Weird. Is this easily reproduceable? I tried for a while with my OpenBSD 3.3/x86, worked fine. Also I can't really even think of when the above error could happen unless something was totally messed up.
It happens when moving lots of messages between folders. Now I have my mail where I want it I will set up a test account that isn't critical to test with.
They copy OK but sylpheed can't delete them afterwards (sylpheed is on lintel)
I have been using hard-linked move, but the problem still occurs without it.
test7 DOES exhibit problems but test6 is rock solid and what I am using now.
--Andrew
On Fri, May 30, 2003 at 11:39:50PM +0100, Andrew Basterfield wrote:
On 30 May 2003 13:24:51 +0300, Timo Sirainen tss@iki.fi wrote:
On Fri, 2003-05-30 at 05:27, Andrew Basterfield wrote:
Now I am getting index corruption again
May 30 03:11:53 snigger imap(bob): Corrupted binary tree file /home/bob/Mail/.INBOX/.imap.index.tree: UID to be inserted isn't higher than existing (1 <= 1)
Weird. Is this easily reproduceable? I tried for a while with my OpenBSD 3.3/x86, worked fine. Also I can't really even think of when the above error could happen unless something was totally messed up.
It happens when moving lots of messages between folders. Now I have my mail where I want it I will set up a test account that isn't critical to test with.
They copy OK but sylpheed can't delete them afterwards (sylpheed is on lintel)
I have been using hard-linked move, but the problem still occurs without it.
test7 DOES exhibit problems but test6 is rock solid and what I am using now.
I think it is related to locking, I have been moving mail around with one client and doing normal operations with another.
I tried to move 2700 messages from a folder on one account to another, I think the problems started when I opened the same folder with another client.
This occurs once in the maillog
May 31 02:20:39 snigger imap(list): Timeout while waiting for release of exclusive fcntl() lock for index file /home/list/Mail/.INBOX/.imap.index May 31 02:26:07 snigger imap-login: Login: bob [127.0.0.1] May 31 02:38:13 snigger imap(bob): Corrupted index file /home/bob/Mail/.Test/.imap.index: Wrong messages_count in header (1247 != 1248)
What happens when the lock times out? Does it carry on regardless or die?
sylpheed says:
** WARNING **: Socket IO timeout ** WARNING **: [03:07:13] Read from socket fd14 failed: Broken pipe ** WARNING **: [03:07:13] error while imap command: STORE 1562:1562 +FLAGS (\Deleted) ** WARNING **: [03:07:13] can't set deleted flags: 1562
and so on many many times
Now I am playing with a test account I can move mail around without interference to see what happens.
-- If at first you don't succeed, destroy all evidence that you tried.
participants (2)
-
Andrew Basterfield
-
Timo Sirainen