Limits and Failure Cases

Severity scale

File moved or renamed

MODERATE

The problem

The layer fingerprint uses the absolute path of the source file. If the file is moved, renamed, or copied elsewhere, the new path produces a different fingerprint. The history recorded under the old path is no longer linked to the layer.

Consequence

The existing history remains intact and browsable (it is not deleted). But RecoverLand does not know that the moved file is the same as the old one. Searching by layer does not show the old history.

How to avoid it

• Do not move data files after you have started editing them in QGIS
• If you must reorganize folders, do it before starting editing work
• Use stable paths (no USB keys, no temporary folders)

Network drive with variable mount point

MODERATE

The problem

If a file is accessible as Z:\share\vegetation.shp on one workstation and as \\server\share\vegetation.shp on another, the two paths produce different fingerprints even though they point to the same physical file.

Same problem if the drive letter changes: Z: one day, Y: the next.

How to avoid it

• Always use the same path to access the file (always the drive letter, or always the UNC path)
• Fix the network drive letter so it does not change between sessions

Unstable FID (shapefile, GeoJSON)

CRITICAL

The problem

The FID of a shapefile is the record number in the .dbf file. This number can change if:

• The shapefile is re-exported ("Save As..." in QGIS or another tool)
• The .dbf file is packed after deletions
• An external script reorganizes the records

How to avoid it

• Use GeoPackage instead of Shapefile when possible
• If you must use a shapefile, do not re-export it between captures and restores
• Before restoring on a shapefile, manually verify that the FID still corresponds to the expected feature

FID = -1 (feature being created)

LOW

The problem

During feature creation (before commit), QGIS assigns a temporary FID of -1. If the plugin captures a snapshot at this moment, the recorded identity is {"fid": -1}, which is not unique.

Real impact

This case is rare because RecoverLand captures at commit time (afterCommitChanges), not during editing. At that point, QGIS has already assigned a definitive FID. The risk is theoretical.

Changes outside QGIS

CRITICAL

The problem

RecoverLand listens to QGIS edit signals. If a file is modified by another application (ArcGIS, Python script, text editor, ogr2ogr), RecoverLand detects nothing. These changes are not in the journal.

How to avoid it

Make all your changes in QGIS. If you must use a script, run it in the QGIS Python console in edit mode (startEditing / commitChanges) so that the signals are emitted.

Recording disabled

CRITICAL

If the user disables the recording toggle, no change is captured. RecoverLand cannot recover what was never recorded. There is no catch-up mode.

Disk full or critically low

CRITICAL

The problem

If the disk hosting the journal drops below 100 MB free, RecoverLand automatically disables tracking. Changes made after that point are not captured.

How it is handled

The DiskMonitor module checks disk space every 5 minutes and at startup. When the critical threshold is reached:

• Recording is automatically disabled
• A red alert appears in the info bar with the free space remaining
• At the warning threshold (500 MB), only an orange notice is shown; recording continues

QGIS crash

LOW

The problem

If QGIS crashes during an edit session (before commit), the in-progress changes are not captured because the commit never happened.

If QGIS crashes after the commit but before the WriteQueue has written to SQLite, a few queued events may be lost. SQLite WAL mode protects events already written.

Real impact

The WriteQueue writes in batches of 500 events or at shutdown. In normal use (a few changes at a time), events are written quickly. The loss risk is limited to a few seconds of activity before the crash.

Recovery mechanism

At startup, the integrity.py module performs several checks:

• PRAGMA integrity_check to detect journal corruption
• WAL checkpoint to consolidate pending writes
• Search for a recoverland_pending.json file containing events not written during the previous crash
• Automatic re-integration of these events with notification to the user

Schema drift

MODERATE

The problem

If a layer's structure changes between capture and restore (field added, removed, renamed, or type changed), the restore may fail or produce an incomplete result.

What RecoverLand does

Before restore, the schema_drift.py module compares the saved schema with the current schema and generates a compatibility report. Missing or incompatible fields are flagged.

Concurrent editing

LOW

RecoverLand is designed for single-workstation use. If two users edit the same file simultaneously, each user has their own journal. A restore by one user may overwrite the other's changes without warning.

This scenario is not supported. For collaborative editing, use a database with a locking system (PostGIS, for example).

Memory layer

LOW

Memory layers have no persistent source file. RecoverLand captures changes informally, but restore is impossible because the layer no longer exists after QGIS is closed.

Journal size

LOW

The problem

The journal grows indefinitely if retention is not configured. On a project with thousands of daily changes, the file can reach several hundred MB.

Impact

Search performance degrades gradually. SQLite remains performant up to several GB, but queries become slower beyond 100,000 events.

Solution

Use the Maintenance dialog to configure a retention policy. For example: keep 90 days of history and purge the rest. The health monitor alerts you when the journal is growing too large before it becomes a problem.

Impact of delta storage

RecoverLand uses delta storage for UPDATE: only the attributes that actually changed are recorded. On a 50-column table, changing one field stores 1 value instead of 50, reducing journal volume by 10 to 50 times compared to a full-row audit.

Journal deleted

CRITICAL

If the .recoverland/recoverland_audit.sqlite file is deleted (manually, by a disk cleanup tool, or by an antivirus), the entire history is permanently lost. RecoverLand will create a new empty journal at the next startup.

QGIS project moved

MODERATE

If you move a QGIS project (.qgz) to another folder, the project_fingerprint changes. The existing journal (which is in the .recoverland/ folder at the old location) is no longer found automatically.

How to avoid it

If you move a project, also move the .recoverland/ folder that is next to the .qgz file. The journal will be found if .recoverland is present next to the project file.

Orphan journals (unsaved projects)

LOW

The situation

When a project is never saved, its journal lives in the QGIS profile directory under a hashed filename (audit_<hash>.sqlite). If the project is closed without saving, this journal file becomes an orphan: it exists on disk but is never opened again.

Automatic cleanup

At startup, the JournalManager scans the unsaved-project audit directory and removes orphan journals older than 30 days (excluding the currently active journal). This cleanup is automatic and silent.

What RecoverLand is not

What RecoverLand is

A local safety net. It automatically records every committed change in a SQLite journal, and allows you to find and restore previous states. It protects against common human errors: accidental deletion, incorrect attribute modification, geometry overwrite.

It works best with strong-identity formats (GeoPackage, PostGIS), on a single workstation, with files that remain at the same location.