Re: [Evolution-hackers] Largefile support

2008-04-15 Thread Milan Crha
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

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Largefile support

2008-04-07 Thread Matthew Barnes
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.

Matthew Barnes

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Largefile support

2008-04-07 Thread Jeffrey Stedfast

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


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Largefile support

2008-04-07 Thread Srinivasa Ragavan
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.

If we are looking at this for Camel, we can go ahead and do the soname
version along with the change.

-Srini

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers