Closing the project/application using the app list instead of double pressing the back button leads to data.gpkg not finalized

[arkanoid87]

If I close QField project using the app drawer instead of double tap on back button, wal and shm files are present in QField project folder (sqlite db not closed).

Not sure if this is a specific issue with my smartphone (Samsung)

Reproduction Steps:

1. Open QField project
2. Add a feature on any layer to trigger write operation on data.gpkg
3. Close QField application opening the app list and swipe up (depends on Android OS, but this is how it's done generally) instead of double pressing the back button.

Expected behavior:

data.gpkg is correctly finalized in project folder

Observed behavior:

data.gpgk, data.gpkg-wal and data.gpkg-shm are present in project folder, where only data.gpkg should exist.

QField version: 1.10.0 (1da006) from Play Store

Additional information:

• Problem started happening recently, didn't happen in an older version of QField: don't know
• Problem can be reliably reproduced, doesn't happen randomly: Yes
• Problem happens with all files and projects, not only some files or projects: Yes

[arkanoid87]

AFAIK, onPause() is the only reliable way to early know the user is leaving: https://developer.android.com/guide/components/activities/activity-lifecycle#onpause

The only exception to this would be force killing the foreground app, that again AFAIK it was a thing only on some custom roms like Lineage.

I don't see onPause declared in any Android Activity

[arkanoid87]

I've verified the same behavior on smartphones and tablets of different brands. Closing the app via overview leaves the db open.

[nirvn]

@arkanoid87 , does this cause any data loss/corruption or it is merely inconvenient to have these sidecar files in your folder?

[arkanoid87]

As sqlite files are memory mapped, a non-closed db may end up being not flushed (depends on OS implementation details afaik). Long story short, syncing gpkg+sidecar may lead to loss or corruption.

Complete explanation at: https://www.sqlite.org/howtocorrupt.html

[gdt]

Having watched the discussion about WAL on qgis, my impression is:

• it's a bug to not close the db (and thus flush/rm journal) when the app is stopped via anything nicer than force close
• the db should only be open in WAL mode if it is editable. Generally, it's best not to cause a write to the filesystem if the app does not have need to do a semantic write operation. I( realize that with tracklogging it's always writeable, but one could and probably should set up tracklogging on a geopackage separate from one's feature geopackage, partially for this reason.)

[nirvn]

QField 2.1 has improved things on that front by upgrading gdal to 3.4.2, which only triggers the WAL mode when editing a geopackage. That should help a lot.

[m-kuhn]

@arkanoid87 , does this cause any data loss/corruption or it is merely inconvenient to have these sidecar files in your folder?

Did someone actually observe data loss?

QField regularly flushes the db to minimize the risk of data loss.

[github-actions[bot]]

The QField project highly values your report and would love to see it addressed. However, this issue has been left in feedback mode for the last 14 days and is being automatically marked as "stale". If you would like to continue with this issue, please provide any missing information or answer any open questions. If you could resolve the issue yourself meanwhile, please leave a note for future readers with the same problem and close the issue. In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this issue. If there is no further activity on this issue, it will be closed in a week.