Re: POLL: what should reconstruct -f do?
On 04/22/2011 08:07 PM, Bron Gondwana wrote: > The question came up from the following bug report: > > http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3449 > > Where there were spool files on disk, but no meta data left. > Reconstruct gave no information about the files on disk at > all. > > I see 4 options, can I'd like some opinions on what people > think reconstruct should do. Speak now(ish) or hold your > peace! > > 1) what we do now - require a cyrus.header in the directory > or ignore it. > > 2) like (1) but warn about the directory with no cyrus.header > > 3) add the mailbox if there's a directory, don't require > cyrus.header. > > 4) like (3) - but check that there's at least one cyrus.* file > OR at least one message file in the directory before > creating the mailbox. (so an empty directory doesn't generate > a bogus mailbox, and neither does one containing nothing that > looks like it belongs in a mailbox) > > > Alright, cast your votes! I'll come back to this thread in a week > or so and implement the winner. (4) is the hardest to implement, > but even that's not very tricky. > > Bron. > > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ I like option 4 with option 3 as a second choice. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: POLL: what should reconstruct -f do?
On Sat, 23 Apr 2011, Bron Gondwana wrote: > The question came up from the following bug report: > > http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3449 > > Where there were spool files on disk, but no meta data left. > Reconstruct gave no information about the files on disk at > all. > > I see 4 options, can I'd like some opinions on what people > think reconstruct should do. Speak now(ish) or hold your > peace! > > 1) what we do now - require a cyrus.header in the directory > or ignore it. > > 2) like (1) but warn about the directory with no cyrus.header > > 3) add the mailbox if there's a directory, don't require > cyrus.header. > > 4) like (3) - but check that there's at least one cyrus.* file > OR at least one message file in the directory before > creating the mailbox. (so an empty directory doesn't generate > a bogus mailbox, and neither does one containing nothing that > looks like it belongs in a mailbox) I think either 3 is the best answer with 4 being a reasonably close second. I tend to be a person who would rather have extra stuff show up and deal with it rather than run the risk of not getting something that I need. I don't think that there's a real problem with creating 'extra' mailboxes if there are extra directories, it's easy enough for the user to delete them. saying that there needs to be a message or a cyrus.* file is a huristic that sounds like it will work most of the time, but not always. David Lang Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
POLL: what should reconstruct -f do?
The question came up from the following bug report: http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3449 Where there were spool files on disk, but no meta data left. Reconstruct gave no information about the files on disk at all. I see 4 options, can I'd like some opinions on what people think reconstruct should do. Speak now(ish) or hold your peace! 1) what we do now - require a cyrus.header in the directory or ignore it. 2) like (1) but warn about the directory with no cyrus.header 3) add the mailbox if there's a directory, don't require cyrus.header. 4) like (3) - but check that there's at least one cyrus.* file OR at least one message file in the directory before creating the mailbox. (so an empty directory doesn't generate a bogus mailbox, and neither does one containing nothing that looks like it belongs in a mailbox) Alright, cast your votes! I'll come back to this thread in a week or so and implement the winner. (4) is the hardest to implement, but even that's not very tricky. Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cvt_cyrusdb before upgrade
On 4/22/2011 12:05 PM, Simon Matter wrote: >> Hello All, >> >> I am looking at upgrading from Cyrus 2.3.16 to 2.4.8. If I convert all >> the dbs from berkeley to skiplist before hand, is there any need to even >> build 2.4.8 with berkeley db support? (Using FreeBSD ports) >> >> I know 2.4.8 will automatically update the dbs, but I figure if I did it >> before hand, I could remove one more dependency from my system. >> >> If so, is there any special trick to running cvt_cyrusdb, or do I just >> shut things down and run it as the cyrus user? > > There is no special trick, at least not one I remember. Just to be sure I > suggest to backup the whole configdirectory firtst. > > Simon > OK, I will give it a try this weekend. Thanks. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cvt_cyrusdb before upgrade
> Hello All, > > I am looking at upgrading from Cyrus 2.3.16 to 2.4.8. If I convert all > the dbs from berkeley to skiplist before hand, is there any need to even > build 2.4.8 with berkeley db support? (Using FreeBSD ports) > > I know 2.4.8 will automatically update the dbs, but I figure if I did it > before hand, I could remove one more dependency from my system. > > If so, is there any special trick to running cvt_cyrusdb, or do I just > shut things down and run it as the cyrus user? There is no special trick, at least not one I remember. Just to be sure I suggest to backup the whole configdirectory firtst. Simon Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
cvt_cyrusdb before upgrade
Hello All, I am looking at upgrading from Cyrus 2.3.16 to 2.4.8. If I convert all the dbs from berkeley to skiplist before hand, is there any need to even build 2.4.8 with berkeley db support? (Using FreeBSD ports) I know 2.4.8 will automatically update the dbs, but I figure if I did it before hand, I could remove one more dependency from my system. If so, is there any special trick to running cvt_cyrusdb, or do I just shut things down and run it as the cyrus user? Thanks Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: sync_client and seenptr
* 22/04/2011, Rudy Gevaert wrote : > > Hi Antonia, please check the devel list :) Antonio ;-) tanx ... -- Never try to teach a pig to sing. It wastes your time and annoys the pig. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: sync_client and seenptr
On Fri, Apr 22, 2011 at 09:15:26AM +0200, Rudy Gevaert wrote: > Hi Antonia, please check the devel list :) Yes, it's a bug - there's a pretty trivial fix for it, and it should have been in 2.4.8 but was missed somehow. Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: sync_client and seenptr
Hi Antonia, please check the devel list :)
On 04/22/2011 07:08 AM, Antonio wrote:
> hi all,
>
> sometimes the sync_client die with the message that a assert failed ...
> I've seen that seen_open() in seen_db.c returns a code != 0 if
> something failed, and the sync_client simply ignore and return 0 in this case
> ...
>
> is necessary the assert check into the code or can i comment out it ?
>
> [CODE]
> sync_client.c
>
> static int do_seen(char *user, char *uniqueid)
> {
> int r = 0;
> struct seen *seendb;
> struct seendata sd;
>
> /* ignore read failures */
> r = seen_open(user, SEEN_SILENT,&seendb);
> if (r) return 0;
> ...
>
> seen_db.c
>
> int seen_open(const char *user,
> int flags,
> struct seen **seendbptr)
> {
> struct seen *seendb = NULL;
> char *fname = NULL;
> int dbflags = (flags& SEEN_CREATE) ? CYRUSDB_CREATE : 0;
> int r;
>
> assert(user);
> assert(*seendbptr == NULL);
> [/CODE]
>
> tanks in advance
>
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
