xRangerDEandClaude Opus 4.7
8d0cb4cefd
Two server-side correctness fixes for parallel downloads and crash recovery. 1. Atomic file writes survive power loss / crash mid-write. saveConfig and writeQueueToDisk used writeFileSync + renameSync. Node's writeFileSync does NOT fsync — a power loss between write and rename can leave the renamed file empty or truncated, and the next launch silently falls back to defaults / empty queue. New writeFileAtomicSync helper: openSync + writeSync + fsyncSync + closeSync + renameSync (with the existing Windows copy fallback). fsync failure is non-fatal (some FS reject it) but file ordering is preserved. 2. Per-item claimed filenames fix the parallel-download race. With max 2 parallel downloads, processOneQueueItem.finally was calling claimedFilenames.clear() — wiping every parallel item's claims when any one finished. In the window between an active item claiming a filename and streamlink actually writing the first bytes, a third item could compute the same filename and both downloads would race the same path. New Map<itemId, Set<filename>> tracks claims per active download. ensureUniqueFilename(path, itemId) registers per-item; releaseClaimedFilenamesForItem(itemId) removes only that item's claims. splitMergedFile gained an itemId parameter for the same reason. The dead releaseClaimedFilename(path) function was removed. Build: tsc clean. Tests: smoke + smoke-template-guide + smoke-full + merge-split + update-version-logic all pass. No new ESLint warnings. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>