Batch-adding multiple .torrent files can rename one torrent to another torrent's name
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 76/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- react, tauri, typescript
Research direction
Start at the AddTorrent entry point and inspect the torrentData effect, the addMutation mapping, and the post-add torrent-rename-path logic shown in the issue. Reproduce the batch case with two single-file torrents, then verify that adding them together preserves each torrent's own info.name and filename without unintended renaming.
Written by the indexing model from the issue text.
Description
Description
When adding multiple .torrent files at once, their contents can be automatically renamed to the name of another torrent from the same batch.
I noticed this with two single-file torrents (each torrent contains one file directly, without a containing folder).
Both torrents have different names, but after selecting and adding both .torrent files at once, the first added torrent ends up with the same filename/name as the other torrent.
Adding the torrents individually does not cause this behavior.
Possibly connected to https://github.com/openscopeproject/TrguiNG/issues/316
Expected behavior
Each torrent should retain its own info.name / payload filename unless I explicitly rename it.
Batch-adding:
- torrent A containing
A.ext - torrent B containing
B.ext
should result in:
A.extB.ext
Actual behavior
One of the torrents is automatically renamed to the name of the other selected torrent.
With two torrents, I observed the first added torrent getting the same name as the last added one (when sorted by Added column).
Environment
TrguiNG:
- Version:
da5a6af - Build date:
8/9/2026, 7:03:05 AM - Frontend: Edge 152.0.0.0 (Blink 152.0.0.0)
- OS: Windows 11
Steps to reproduce
- Call Add torrent file menu
- Add 2 single-file torrent files at once.
Chatgpt thoughts:
The issue also appears to still be present in the current master source.
This can be reproduced without using a tracker:
-
Create two different single-file
.torrentfiles locally, e.g.:- torrent A with internal name
A.bin - torrent B with internal name
B.bin
- torrent A with internal name
-
In TrguiNG, select both
.torrentfiles at the same time in the Add Torrent dialog. -
Add them, preferably with "Start torrent" disabled.
-
Check their names/files in Transmission.
One torrent may be renamed to the name belonging to another torrent from the batch.
Suspected cause
AddTorrent stores a single torrentName for the entire batch:
useEffect(() => {
if (torrentData === undefined || torrentData.length < 1) setTorrentName("");
else setTorrentName(fileSystemSafeName(torrentData[0].name.replace(/\.torrent$/i, "")));
}, [torrentData]);
But while adding multiple torrents, this same torrentName is passed for every td:
Promise.all(torrentData.map(async (td) => {
return await addMutation.mutateAsync({
...
metainfo: td.metadata,
...
name: torrentName,
filePath: td.torrentPath,
});
}));
Then, after Transmission successfully adds each torrent, TrguiNG compares the torrent's actual name against that shared name and issues torrent-rename-path:
const safeName = fileSystemSafeName(vars.name ?? "_");
if (TAURI && added.name != safeName) {
pathMutation.mutate({
client: vars.client,
torrentId: added.id,
path: added.name,
name: safeName,
});
}
As a result, every torrent whose original name differs from the single shared torrentName can be renamed to that name.
For batch additions, it seems the rename name should instead be derived from the corresponding td.name, while the editable torrentName field should probably only apply when exactly one torrent is being added.
For example, something along the lines of:
name: torrentData.length === 1
? torrentName
: fileSystemSafeName(td.name),
or otherwise disabling the custom rename mechanism entirely for multi-torrent additions.
- Dominant language
- TypeScript
- Stars
- 819
- Forks
- 109
- Avg merge
- 8d 57m
- Merged PRs (30d)
- 2
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from openscopeproject/TrguiNG
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
openscopeproject/TrguiNG#338 ·
-
Difficulty 4/5 1-2 days Newbie friendliness 35/100
openscopeproject/TrguiNG#345 · 1 comment ·
-
fix-committed
Difficulty 4/5 3-5 days Newbie friendliness 42/100
openscopeproject/TrguiNG#336 · 17 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 67/100
openscopeproject/TrguiNG#333 · 5 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
openscopeproject/TrguiNG#332 · 1 comment ·
All issues in openscopeproject/TrguiNG
Similar issues
-
needs investigation
Difficulty 2/5 1-3 hours Newbie friendliness 60/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
area:visualizer tech-debt
Difficulty 2/5 Under an hour Newbie friendliness 66/100
jmbarzee/temporal-architect#292 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
riverqueue/river#1576 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
colbymchenry/codegraph#3228 ·
Maintainers usually reply within 1 day