> My guess is that you are probably overflowing a 32-bit integer
> someplace.  If so, I fear that this will not be something easily
> fixed.

Looks like it's the case at least in one place.
There's int64 => unsigned int overflow at the call to blob_resize()

Generally this is tied to the way the Blob type is defined, so the fix
indeed may be painful and involve thorough testing.
This only becomes an issue with LARGE file sizes that overflow the
(unsigned int), which as DRH mentioned is somewhat beyond the expected
Fossil use-cases.

From the code I don't see any easy workaround other than addressing
the sizes of the files stored at the client's end.

May be trying to build a 64-bit version of the Fossil and explicitly
force the int to 64-bit size
BUT this may blow in some other place, so I would not trust it even if
it worked.

I also wonder at effectiveness of tracking the binaries, as these
won't diff properly, thus each new version would likely be stored
entirely, which would kinda turns repo into a gigantic zip archive
with a lot of overhead. I'd rather keep track of a __reference__ to
such binaries, while the binaries could be stored at some other bulk
storage location. Thus a project version would fetch an updated
reference and the pull the resp. binary.


rc = blob_read_from_file(&disk, zFullpath, RepoFILE);


sqlite3_int64 blob_read_from_file(
  Blob *pBlob,               /* The blob to be initialized */
  const char *zFilename,     /* Extract content from this file */
  int eFType                 /* ExtFILE or RepoFILE - see above */
  sqlite3_int64 size, got;

  size = file_size(zFilename, eFType);
  blob_resize(pBlob, size);


void blob_resize(Blob *pBlob, unsigned int newSize){
  pBlob->xRealloc(pBlob, newSize+1);
   pBlob->nUsed = newSize;
   pBlob->aData[newSize] = 0;
fossil-users mailing list

Reply via email to