32-bit to 64-bit migration seen flags

[Bron Gondwana]

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.