On Mon, Jan 12, 2009 at 11:20:07AM -0500, Wesley Craig wrote: > On 12 Jan 2009, at 04:26, ram wrote: > > On Fri, 2009-01-09 at 11:53 -0500, Wesley Craig wrote: > >> How are you copying? > > > > scp-ing the files > > Well, the data in the seen files is stored by unique ID of the > mailbox -- which is stored as a string. The data stored is the "seen > version" (which has been 1 for a long time), the last read time > (time_t cast to int), last uid (int), last change time (time_t cast > to int), and seen uids (a string created earlier from unsigned long). > > I suppose it's possible that the casts of time_t to int are > corrupting your results. What value is time_t on your system? It > absolutely true that casting time_t to int is *wrong*, and should be > handled in some other way, e.g., TIME_T_FMT. Of course, that has > (different) implications for migrating between platforms as well. Yeah - when I was playing with skiplist2 a while back, I set aside 64 bits for each time value (there are only a couple of them in the header, and we have spare slots in the header anyway. > You might try dumping the data with cyr_dbtool on yor 32-bit system > and reloading it with cyr_dbtool on your 64-bit system. I doubt that > will help, but you never know. I think a much more likely scenario > is that however you're copying the mailboxes is causing the unique ID > of the mailboxes to be re-assigned. Since all of the data in the > seen DB is keyed on the unique ID of the mailbox, if the unique ID of > the mailbox changes, all of the seen data is effectively lost. > Probably a uid validity change would have a similar effect. the uniqueid is stored in the cyrus.header file. If you're copying the cyrus.header files then you shouldn't lose it. Bron. ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
