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 *** |