Opened 16 years ago
Last modified 6 years ago
#856 new bug
Torrents sharing same folder name issue
Reported by: | jeff@tjwallace.ca | Owned by: | andar |
---|---|---|---|
Priority: | minor | Milestone: | not applicable |
Component: | libtorrent | Version: | 1.2.0 |
Keywords: | Cc: |
Description
If you are downloading multiple torrents that are downloading into the same folder, and one of the torrent's finishes, the whole folder (and contents) is moved even though the unfinished torrents have files in that folder. The unfinished torrents get an error and stop.
I disovered this bug downloading the slackware install iso's.
Change History (10)
comment:1 by , 15 years ago
Version: | 1.1.5 → 1.2.0_rc3 |
---|
comment:2 by , 15 years ago
Component: | other → libtorrent |
---|
comment:3 by , 15 years ago
Version: | 1.2.0_rc3 |
---|
comment:4 by , 15 years ago
Component: | libtorrent → core |
---|---|
Milestone: | → 1.4.0 |
Priority: | major → minor |
Summary: | Move Completed Torrents Bug → Torrents sharing same folder name issue |
Version: | → 1.2.0 |
comment:5 by , 15 years ago
Component: | core → libtorrent |
---|---|
Milestone: | 1.4.0 |
johnnyg pointed out it is an lt issue that can be solved by doing a recursive move
follow-up: 7 comment:6 by , 14 years ago
They shouldn't share the same folder in the first place, it should be impossible to assign for any new torrent a folder name that is already taken. If that is attempted, deluge should prompt for an alternative name, maybe suggesting a (2) suffix as mentioned.
comment:7 by , 14 years ago
Replying to caramba:
They shouldn't share the same folder in the first place, it should be impossible to assign for any new torrent a folder name that is already taken. If that is attempted, deluge should prompt for an alternative name, maybe suggesting a (2) suffix as mentioned.
Come on, it should be impossible? No it should not be impossible. It should though, only move the files belonging to the torrent that completed.
comment:8 by , 12 years ago
Milestone: | → not applicable |
---|
comment:9 by , 8 years ago
This problem still exists in Deluge 1.3.12, as it has just happened to me, and caused a fair amount of frustration figuring out what happened.
The fundamental problem is not LibTorrent, it is how LibTorrent is being used. The bug is not that two torrents can use the same folder (though that should be addressed as a separate bug), the bug is that files in that folder are blindly moved along with the target files when a torrent is moved when finished. Only the sub-folders/files that are listed in the torrent file should be moved, not blindly the top-level folder and everything in it.
comment:10 by , 6 years ago
this is still a problem in Deluge 1.3.15
They shouldn't share the same folder in the first place
agree
it should be impossible to assign for any new torrent a folder name that is already taken.
no, it should be possible when explicitly needed, but it should not be the default behavior. obviously, in the "move storage" operation, files must be selected from the torrent file list, and not from the storage folder.
I also wounder how Deluge handles multiple torrents with the exact same file names in addition to the directory names, does one get overridden?
this is my problem: file name collision. how did deluge react? deluge did concat the two files, file two was appended at the end of file one.
a fair amount of frustration
yes. please just fix these ridiculous bugs
I have also run into this bug on 2 separate occasions now.
It's not uncommon for multiple torrents to have the same name, you get things like 'ebooks', 'PDFs'.
Still happens with 1.2.0-rc3
I also wounder how Deluge handles multiple torrents with the exact same file names in addition to the directory names, does one get overridden?.
Maybe the best solution is to rename the new directory something like "directory (1)", although it would need to be scanned first to see if it is indeed different (since you don't want to accidently re-add a torrent a few times and end up with file dupes). You would probably only want that happing if there is a filename conflict though since it would be stupid to have "slackwareiso (1)/slack64bit.iso", "slackwareiso (2)/slack32bit.iso", ect... although it might be best to have the behavior set as a user config option since you might not want, say, a huge number of rar files mixing together even if they are different names.