Problem
Save-PathBackup (Windows-Path-Repair-Full.ps1, ~line 225) names backups with a second-resolution timestamp (PATH-backup-yyyyMMdd-HHmmss.json) and writes with Set-Content, which overwrites an existing file. Two applies within the same second overwrite the first backup — and the first backup is exactly the one holding the true pre-change state, so the original PATH values are lost.
Proposed fix
- Make filenames collision-proof: add milliseconds plus a short random suffix, e.g.
PATH-backup-yyyyMMdd-HHmmss-fff-<4 hex>.json.
- Belt-and-suspenders: create the file atomically/no-clobber (
New-Item -ItemType File without -Force, or [IO.File]::Open with CreateNew) and retry with a new name on collision, so an overwrite is impossible even if the naming scheme changes later.
Acceptance criteria
- Two back-to-back
Save-PathBackup calls in the same second produce two distinct files with both original values intact.
- Test covering the collision behavior (call twice rapidly under
$TestDrive, assert two files).
- README backup section unchanged except the filename pattern example.
Priority: P2 — the backup is the tool's last-resort recovery mechanism.
Problem
Save-PathBackup(Windows-Path-Repair-Full.ps1, ~line 225) names backups with a second-resolution timestamp (PATH-backup-yyyyMMdd-HHmmss.json) and writes withSet-Content, which overwrites an existing file. Two applies within the same second overwrite the first backup — and the first backup is exactly the one holding the true pre-change state, so the original PATH values are lost.Proposed fix
PATH-backup-yyyyMMdd-HHmmss-fff-<4 hex>.json.New-Item -ItemType Filewithout-Force, or[IO.File]::OpenwithCreateNew) and retry with a new name on collision, so an overwrite is impossible even if the naming scheme changes later.Acceptance criteria
Save-PathBackupcalls in the same second produce two distinct files with both original values intact.$TestDrive, assert two files).Priority: P2 — the backup is the tool's last-resort recovery mechanism.