Skip to content

Robust contacts - backup first before saving and fallback to backup file#1447

Open
weebl2000 wants to merge 3 commits intomeshcore-dev:devfrom
weebl2000:robust-contacts
Open

Robust contacts - backup first before saving and fallback to backup file#1447
weebl2000 wants to merge 3 commits intomeshcore-dev:devfrom
weebl2000:robust-contacts

Conversation

@weebl2000
Copy link
Contributor

@weebl2000 weebl2000 commented Jan 22, 2026

Problem: Contacts sometimes partially disappear on Heltec v4 and Heltec Wireless Tracker v1.2. This is likely caused by power loss or reset during a direct overwrite of the contacts file.

Solution: Atomic-style write pattern for saveContacts:

  1. Write contacts to a temporary file (/contacts3.tmp)
  2. Flush to ensure data is on flash
  3. Rename existing /contacts3/contacts3.bak
  4. Rename /contacts3.tmp/contacts3
  5. Remove /contacts3.bak (no longer needed until next save)

If the write fails mid-save, the .tmp file is removed and the original contacts file is left untouched.

On load, if /contacts3 is missing or empty, loadContacts falls back to /contacts3.bak automatically. This covers the edge case where power is lost between steps 3 and 4.

Platform guard: Only enabled on devices with sufficient flash for the temporary file (~2x contacts storage during save). Disabled on NRF52 unless EXTRAFS or QSPIFLASH is defined.


Build firmware: Build from this branch

@weebl2000 weebl2000 changed the base branch from main to dev January 22, 2026 07:42
@weebl2000 weebl2000 force-pushed the robust-contacts branch 3 times, most recently from 9778b43 to 06dc6f5 Compare February 11, 2026 04:13
@weebl2000
Copy link
Contributor Author

I think what actually caused the contacts to miss in the first place was the nodeinfo files that were written regardless of auto-add contacts.

weebl2000 and others added 3 commits February 26, 2026 23:16
The fs->remove("/contacts3.bak") before the rename sequence creates a
vulnerability window: if power is lost right after removing the backup
but before the rename completes, both the backup and primary file could
be lost. The remove is unnecessary since rename() on both SPIFFS and
LittleFS replaces the target if it already exists.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant