Is there a file size limitation Calc ods file

[jspreadsheet]

Last Nov after accessing an ods file I was hit with the error message “The file is … corrupt and therefore cannot be opened … can try to repair the file … this document.” I rebuilt the profile dealt with the “rabbit hole” that the file corruption error took me. I did not get back to any normalcy until I removed a sheet from a previous backup of the problem file. It was reduced to 1.5 gig from 2.0 gig.

Things went rocking along until the same corrupt issue cropped up again as I reached a file size of 2.0 gig.
Knowing I was nearing this threshold I had been backing up this ods file daily to another internal drive with the same OS. I moved this last backup to my main working drive and overwrote the reported corrupt file. No corrupt file message appeared when accessed. Great, but how can I continue any further work if I cannot get past what seems to be an apparent 2 gig limitation?

Given: LibreOffice 7.0.3.1 00(Build:1)
16G System memory processor AMD Ryzen 5 2600 Six-Core Processor
ubuntu 20.04 5.4.0-65-generic #73-Ubuntu

Filesystem     1K-blocks      Used            Available     Use% Mounted on
/dev/sda2      481389624   128030008 328836636  29%     /

[Edit Opaque] Changed filesystem info to pre-formatted text

[anon73440385]

Which filesystem type are you using on /dev/sda2 - is it ext4 or something else? What does ulimit -a tell about file size?

[jspreadsheet]

It is ext4 with “unlimited” response to ulimit command
Additional note: I overwrote the corrupt file with the backed up file again, deleted the contents of one cell, tried to save but it took down the rabbit hole again after attempting recovery.

[anon73440385]

And you save as .ods or some uncompressed xml file format?

[mikekaganski]

There is technical limitation that standard imposes on the file size per se. ZIP APPNOTE Version 6.2.0 allows using 64-bit file format, making it unlimited for practical purposes. However, large files are not used widely, and thus not tested in practice, which allows to have multiple corner-case bugs lurking around unnoticed, e.g. because of wrong use of 32-bit integers somewhere.

[jspreadsheet]

I worked around the problem by separating a sheet with hyperlink objects to the main body as a file.
Strangely enough when I total the main sheet (850m) and the separated file (only 1m) it is less than half of the suspected 2Gig limit.

[jspreadsheet]

I had to split off a sheet containing hyperlinks to the main body.
Strangely enough the total size(1M and 810M)of the 2 separated files is less than 1G, half of the suspect 2 gig limitation.