|
From: Gunter O. <G.O...@po...> - 2006-11-07 18:22:43
|
Am Dienstag, 7. November 2006 17:04 schrieb Gunter Ohrner:
> Thanks a lot, I just started a new sync with the md5 algorithm.
Ok, this one failed badly; causing mailsync to abort with a SIGABRT nearly=
=20
immediately. Details can be found below if anyone is interested, took it=20
as a sign to restart with a fresh msinfo location.
With a fresh msinfo location and mailsync started its work, however it=20
began dublicating some mails in some folders which definitely had not=20
been touched except by the IMAP-servers on both sides (of course) and=20
mailsync itself. It did neighter duplicate all mails in the affecteed=20
folders, just some, and not all folders where affected (or maybe simply=20
not all folders contain messages which trigger this behaviour).
I randomly chose one mail to which this had happened - it was now=20
available twice in both stores - and saved it into a text file using my=20
MUA. A diff on the textfile displayed a changed X-UID on the remote side=20
as the only changes:
******************************
$ for OLD in 1 2 ; do for NEW in 1 2 ; do echo "Original store #$OLD; new=20
store #$NEW:" ; diff "msg${OLD}_origstore.txt" "msg${NEW}_newstore.txt" ;=20
done ; done
Original store #1; new store #1:
Original store #1; new store #2:
41c41
< X-UID: 16
=2D--
> X-UID: 55
Original store #2; new store #1:
41c41
< X-UID: 52
=2D--
> X-UID: 16
Original store #2; new store #2:
41c41
< X-UID: 52
=2D--
> X-UID: 55
$ diff msg1_origstore.txt msg2_origstore.txt
41c41
< X-UID: 16
=2D--
> X-UID: 52
$
******************************
Is this more likely the problem's cause or one of its effects?
I aborted the run and re-ran "mailsync -s" just to see what the next=20
mailsync run would do. I detected the (newly created) duplicates in both=20
stores and removed them from both stores, just to copy them again...=20
=46unky...
Has anyone any clue what's happening here? So far it looks as if mailsync=20
does not lose mail and that it does not indefinitely duplicate mails (as=20
it detects its self-created duplicates) but I'm not sure if I like to lay=20
my mails in the hands of a shoftware which shows such effects...
The remote site (new store) is running a Cyrus 2.2.12 server=20
(v2.2.12-Debian-2.2.12-4ubuntu1), my local server is a Dovecot 1.0beta5.=20
The only MUA which accessed both IMAP stores in the meantime is kMail=20
1.9.5.
I wonder what's going on there...
Greetings,
Gunter
PS: Mailsync-crash with "-t md5" and a "-t msgid" msinfo store:
I installed Debian Sarge's mailsync package so the backtrave is probably=20
entirely useless, though I included it anyway just for the sake of=20
completeness.
It did only crash if called with "-t md5", also when simulating.
The output:
******************************
$ mailsync -s -t md5 do-sync
Only simulating
Synchronizing stores "schli-store" <-> "local-store"...
Authorizing against {h1050806.serverkompetenz.net/imap}
Authorizing against {Hb/imap}
Authorizing against {Hb/imap}
Authorizing against {Hb/imap}
Aborted (core dumped)
$
******************************
The backtrace:
******************************
(gdb) bt
#0 0x4032b741 in kill () from /lib/libc.so.6
#1 0x4032b4c5 in raise () from /lib/libc.so.6
#2 0x4032ca08 in abort () from /lib/libc.so.6
#3 0x4fb5f317 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.5
#4 0x4fb5f354 in std::terminate () from /usr/lib/libstdc++.so.5
#5 0x4fb5f4c6 in __cxa_throw () from /usr/lib/libstdc++.so.5
#6 0x4fb14f90 in std::__throw_out_of_range ()=20
from /usr/lib/libstdc++.so.5
#7 0x0805f39c in std::operator+<char, std::char_traits<char>,=20
std::allocator<char> > ()
#8 0x0805cff2 in std::operator+<char, std::char_traits<char>,=20
std::allocator<char> > ()
#9 0x0804a9be in ?? ()
#10 0x40317e36 in __libc_start_main () from /lib/libc.so.6
#11 0x0804a401 in ?? ()
******************************
=2D-=20
*** Powered by AudioScrobbler --> http://www.last.fm/user/Interneci/ ***
17:35 | Elwood - stompin little scouts
17:31 | Elwood - Waverider
17:26 | Elwood - I Can Seek
17:21 | Scooter - Trip to Nowhere (Bonus)
*** PGP-Verschl=FCsselung bei eMails erw=FCnscht :-) *** PGP: 0x1128F25F ***
|