This issue is intended to be a compilation of crashes caused (apparently) by too much data in SQL. We've patched some of these in the past but it's evident that a more integral solution or rework is needed to stop this happening all the time.

Issues

Row too big to fit in CursorWindow

• Crash: SQLiteBlobTooBigException in thread main via FileDataStorageManager.getFolderContent() #10199
• Android Client crash while upload and don't recover: android.database.sqlite.SQLiteBlobTooBigException #10150
• SQLiteBlobTooBigException with a large README.md #9693
• File list crashed after login: android.database.sqlite.SQLiteBlobTooBigException #9384
• many more closed ones

Couldn't read row... Make sure Cursor is initialized

• Instant upload folder in Android app often crashes #10193
• Crash scrolling media view #10192
• Couldn't read row ... Make sure the Cursor is initialized at createFileInstance #9948
• Couldn't read row ... Make sure the Cursor is initialized at deleteDirectory #6103
• Android app crash #10245
• Exception: com.nextcloud.client.database.dao.FileDao_Impl.getGalleryItems #11399
• many more closed ones

Causes

The filelist table has several columns that can grow indefinitely, causing this problem:

• rich_workspace contains, for folders, the entire contents of the README.md file for that folder.
  • This is likely the biggest cause of this crash, as it's very easy to create a README.md file over 2mb in size (by adding a lot of embedded images, for example). good example in SQLiteBlobTooBigException with a large README.md #9693.
  • This should just not be stored in a sql database, period.
  • Ideas:
    * store the README as a file in private storage and use this field as a reference to that file
    * store the first N lines of the README, only fetch the entire one when displaying it.
    * don't store the README at all, just grab the contents from the README file when displaying the folder.
• sharees contains a json-encoded list of sharees for the file. This grows indefinitely as more sharees are added.
  • Crash could be possible if a file has tons of sharees. However this should be rather hard to trigger if not on purpose; even a column with 1000 sharees will only occupy around 100 kB
  • This should be stored in a separate table and JOINed when querying, or something like that. Not sure if that is even possible with the current ContentResolver approach.
• note contains the note added to the share when sharing.
  • Not sure if this can be of arbitrary length, but it's likely not as easy to make grow as only plaintext is possible.

In the past, we've mitigated this issue at some places by using a projection to avoid fetching all columns. However, when retrieving a list of OCFiles, there's no way around this as we actually do want all fields. To really fix this we'll need to change how the fields above are handled.

We could mitigate this further by increasing the cursor size (supported on android>=9, and possible via reflection before that) to something like 50 mB instead, but that will just make the problem less common instead of fixing it.

cc @tobiasKaminsky