Re: [Evolution-hackers] Largefile support

[Milan Crha <mcrha redhat com>]

On Mon, 2008-04-07 at 14:23 -0400, Jeffrey Stedfast wrote:
> On Mon, 2008-04-07 at 13:29 -0400, Matthew Barnes wrote:
> > On Mon, 2008-04-07 at 12:43 -0400, Jeffrey Stedfast wrote:
> > > The only 'gotcha' I can think of by enabling it by default is that it
> > > might break ABI if old builds were 32bit off_t's (the new off_t's would
> > > be 64bit).
> > 
> > 
> > > Oh, and fwiw, looking ahead, it may even be worth changing the public
> > > API to take goffset's rather than off_t's if breaking API is acceptable
> > > since it will prevent future off_t size issues (since I believe that
> > > goffset is supposed to be an int64_t)
> > 
> > Yeah, and this would be the opportune time to do that if we're going to
> > (early in the development cycle).  Sounds like we should wait to enable
> > largefile support by default until we do the goffset replacement, and
> > then ship both changes at once with a soname bump.
> 
> sounds reasonable to me
> 
> Jeff

	Hi Jeff,
I looked a bit at this, and even it seemed as 'find and replace' work,
then it finally showed up that off_t is saved in a summary file.

I'm not sure how to properly (and in the simplest way) handle this. The
only thing I can think of is bump summary file version to indicate all
offsets are 64bit regardless of the machine architecture, and for those
old version files read the offset either as 32 bit or 64 bit. The
problem is, when we turn on the large file support, then I cannot
recognize what was the old size of off_t (before turning this on). Maybe
I can do it with sizeof(int), which will tell me whether I'm on 32 or 64
bit machine, but it seems kinda strange (and smells like hack) to me.
Also, I didn't check code completely, but is it right that summaries are
overwritten always whole or did I misread code?

Maybe there is better way, just drop summary if it's an old version and
rebuild it, but I do not want to go by this way, because for local
summaries there are (more or less) important data like user tags/flags,
which I believe we should not delete to the user.

Maybe any migration code? I still think I will need to know the old size
of off_t anyway. And I would like to do that as much transparent as
possible.

What is your idea?

	Bye and thanks,
	Milan