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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user