Backup directory failures must not crash the whole server

A fresh Windows install reported the server failing around backups.
createBackupService created the backups subdirectory once, synchronously,
at startup with no error handling - any failure there (permissions, a
path beyond Windows' MAX_PATH, a OneDrive/cloud-sync lock, antivirus)
crashed the entire Node process before it started listening, taking
down timing with it instead of just leaving backups unavailable.

Directory creation is now retried lazily and non-fatally on each backup
attempt, and a post-backup file rename retries briefly on EBUSY/EPERM
since a freshly written file is sometimes momentarily locked by
antivirus/cloud-sync scanning on Windows.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
larssand
2026-09-09 10:59:39 +02:00
parent 2846b4c0fe
commit c53f31bf35
6 changed files with 77 additions and 7 deletions

View File

@@ -8,6 +8,12 @@ The application version is maintained in `package.json` and displayed in the adm
No changes recorded yet.
## 1.4.1 - 2026-09-09
### Fixed
- A backup failure at startup (e.g. no write permission for the backups folder, a path beyond Windows' MAX_PATH, a OneDrive/cloud-sync folder locking it, or antivirus interference) could crash the entire server before it started listening, instead of just leaving backups unavailable. Backup-directory creation is now non-fatal and retried on each backup attempt, and a file rename right after a backup completes now retries briefly if a file is momentarily locked by antivirus/cloud-sync scanning.
## 1.4.0 - 2026-09-09
### Added