Fix duplicate (1) filenames after app restart with partial downloads
When the app restarts (or updates) while downloads are in progress, partial files remain on disk but reservedTargetPaths (in-memory) is empty. claimTargetPath treated the unclaimed-but-existing file as a conflict and appended (1) to the filename, breaking RAR split archive extraction. Fix: if a file exists on disk but no other item has reserved the path, allow overwriting instead of creating a duplicate. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
parent
31a579f07c
commit
cb02dd3aac
@ -3942,7 +3942,10 @@ export class DownloadManager extends EventEmitter {
|
||||
const owner = this.reservedTargetPaths.get(key);
|
||||
const existsOnDisk = fs.existsSync(candidate);
|
||||
const allowExistingCandidate = allowExistingFile && index === 0;
|
||||
if ((!owner || owner === itemId) && (owner === itemId || !existsOnDisk || allowExistingCandidate)) {
|
||||
// If file exists on disk but no other item has reserved this path, allow overwrite.
|
||||
// This prevents "(1)" suffixes after app restart when partial downloads remain on disk.
|
||||
const unclaimedOnDisk = existsOnDisk && !owner && index === 0;
|
||||
if ((!owner || owner === itemId) && (owner === itemId || !existsOnDisk || allowExistingCandidate || unclaimedOnDisk)) {
|
||||
this.reservedTargetPaths.set(key, itemId);
|
||||
this.claimedTargetPathByItem.set(itemId, candidate);
|
||||
return candidate;
|
||||
|
||||
Loading…
Reference in New Issue
Block a user