Re: repairing a calendar
On 20/12/17 20:57, Ken Murchison wrote: > The mailbox types for the broken user's DAV mailboxes are wrong. Type 0 > (zero) says its a regular email mailbox. You'll have to change them to 32 > for calendars and 64 for addressbooks. Ok, fixed it with ctl_mboxlist, but $ dav_reconstruct Reconstructing DAV DB for ... Inserting DAV DB entries for user..#addressbooks... Inserting DAV DB entries for user..#addressbooks.Default... Inserting DAV DB entries for user..#calendars... Inserting DAV DB entries for user..#calendars.Default... Segmentation fault ...at this point I'll move this thread to github issue tracker. It seems both XFER and dav_reconstruct are broken an 2.5.11. Greetings, Wolfgang -- Wolfgang Breyha | http://www.blafasel.at/ Vienna University Computer Center | Austria Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: repairing a calendar
The mailbox types for the broken user's DAV mailboxes are wrong. Type 0 (zero) says its a regular email mailbox. You'll have to change them to 32 for calendars and 64 for addressbooks. On 12/20/2017 02:54 PM, Wolfgang Breyha wrote: On 20/12/17 17:35, Ken Murchison wrote: Try: dav_reconstruct Oh sorry, didn't find that one... but doing so removes the .dav file without generating a new one. So I assume that something happend XFERing that mailbox destroying important information about DAV mailboxes. strace shows that dav_reconstruct unlinks the DB and scans mailboxes.db afterwards. And then it ends without further steps. Looking at a ctl_mboxlist dump... $ ctl_mboxlist -d|grep user. user..#addressbooks 0 part18 lrswipkxtecdan user..#addressbooks.Default 0 part18 lrswipkxtecdan user..#calendars 0 part18 lrswipkxtecdan user..#calendars.Default 0 part18 lrswipkxtecdan user..#calendars.Inbox 0 part18 lrswipkxtecdan user..#calendars.Outbox 0 part18 lrswipkxtecdan compared to a working one... user..#addressbooks64 part06 lrswipkxtecdan user..#addressbooks.Default64 part06 lrswipkxtecdan user..#calendars 32 part06 lrswipkxtecdan user..#calendars.Default 32 part06 lrswipkxtecdan user..#calendars.Inbox 32 part06 lrswipkxtecdan user..#calendars.Outbox32 part06 lrswipkxtecdan I guess there are missing important flags on those DAV folders. Most likely "lost in translation^WXFER". Should I file a bug? BTW(ab)using dav_reconstruct with user. instead of causes a SIGSEGV. Greetings, Wolfgang -- Kenneth Murchison Cyrus Development Team FastMail Pty Ltd Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: repairing a calendar
On 20/12/17 17:35, Ken Murchison wrote: > Try: > > dav_reconstruct Oh sorry, didn't find that one... but doing so removes the .dav file without generating a new one. So I assume that something happend XFERing that mailbox destroying important information about DAV mailboxes. strace shows that dav_reconstruct unlinks the DB and scans mailboxes.db afterwards. And then it ends without further steps. Looking at a ctl_mboxlist dump... $ ctl_mboxlist -d|grep user. user..#addressbooks 0 part18 lrswipkxtecdan user..#addressbooks.Default 0 part18 lrswipkxtecdan user..#calendars 0 part18 lrswipkxtecdan user..#calendars.Default 0 part18 lrswipkxtecdan user..#calendars.Inbox 0 part18 lrswipkxtecdan user..#calendars.Outbox 0 part18 lrswipkxtecdan compared to a working one... user..#addressbooks64 part06 lrswipkxtecdan user..#addressbooks.Default64 part06 lrswipkxtecdan user..#calendars 32 part06 lrswipkxtecdan user..#calendars.Default 32 part06 lrswipkxtecdan user..#calendars.Inbox 32 part06 lrswipkxtecdan user..#calendars.Outbox32 part06 lrswipkxtecdan I guess there are missing important flags on those DAV folders. Most likely "lost in translation^WXFER". Should I file a bug? BTW(ab)using dav_reconstruct with user. instead of causes a SIGSEGV. Greetings, Wolfgang -- Wolfgang Breyha | http://www.blafasel.at/ Vienna University Computer Center | Austria Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: repairing a calendar
Try: dav_reconstruct On 12/20/2017 11:29 AM, Wolfgang Breyha wrote: Hi! I'm currently debugging some oddities with a users default calendar after the mailbox got XFER'ed to a different murder backend. The whole setup uses 2.5.11 currently. After lightning started to fail the user removed the calendar and added it again. lightning now tries to fetch the whole calendar (about 100 entries). I see the REPORT request which gets a Multi-Status response with all ics URIs and 200 OK. After that I see the calendar-multiget request for all these URIs. But this request gets a HTTP/1.1 404 Not Found response. I assume that at least one of the URIs fails. strace does not give any clues which one. The session trace from cyrus doesn't help as well. dumping the .dav sqlite DB it seems that there are at least 2 entries (the latest ones after the XFER) which are not in the DB table and only in the filesystem. The timestamp of the .dav DB is exactly from the XFER and not from the newer entries found in the calendar folder. Currently I'm searching my logs if there is something odd after the XFER especially while the new entries got added. While doing that the general questions raised how to repair a calendar at all, since reconstruct does not do it as it seems? At least the .dav sqlite database is not rebuilt. Removing the .dav file does no good as well. I get an empty one after the next access to the calendar. But it is still not accessible/syncable. Greetings, Wolfgang -- Kenneth Murchison Cyrus Development Team FastMail Pty Ltd Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
repairing a calendar
Hi! I'm currently debugging some oddities with a users default calendar after the mailbox got XFER'ed to a different murder backend. The whole setup uses 2.5.11 currently. After lightning started to fail the user removed the calendar and added it again. lightning now tries to fetch the whole calendar (about 100 entries). I see the REPORT request which gets a Multi-Status response with all ics URIs and 200 OK. After that I see the calendar-multiget request for all these URIs. But this request gets a HTTP/1.1 404 Not Found response. I assume that at least one of the URIs fails. strace does not give any clues which one. The session trace from cyrus doesn't help as well. dumping the .dav sqlite DB it seems that there are at least 2 entries (the latest ones after the XFER) which are not in the DB table and only in the filesystem. The timestamp of the .dav DB is exactly from the XFER and not from the newer entries found in the calendar folder. Currently I'm searching my logs if there is something odd after the XFER especially while the new entries got added. While doing that the general questions raised how to repair a calendar at all, since reconstruct does not do it as it seems? At least the .dav sqlite database is not rebuilt. Removing the .dav file does no good as well. I get an empty one after the next access to the calendar. But it is still not accessible/syncable. Greetings, Wolfgang -- Wolfgang Breyha | http://www.blafasel.at/ Vienna University Computer Center | Austria Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
