starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

Multiple torrents with same name don't handle well #4635

New issue

Closed

opened 2026-02-21 17:25:23 -05:00 by deekerman · 13 comments

deekerman commented

2026-02-21 17:25:23 -05:00

Owner

Originally created by @teotikalki on GitHub (Aug 22, 2016).

I've been experiencing an issue recently where multiple torrents with the same name (at the time of this writing the most recent example was 'Wing Chun') 'get confused'. What happens is that they end up downloading into the same folder (right now that is the /~Incomplete directory inside my root torrent directory) and when one of the torrents finishes, it moves the whole folder out of the incomplete folder, thus breaking the other torrent (the one that didn't finish). I then have to manually sort through the files list, move one set back to my ~Incomplete, and 'Force Recheck'.

It seems that it would be fairly simply to implement something like most file managers do where additional torrents with the same name get (1), (2), (etc) appended to them (as a default) and possibly to have the ability to choose the suffix possibly (similar in function to how you can choose a custom append string for incomplete torrents, etc).

I doubt that this comes up for many people; my torrenting habits could best be described as 'archivist'. I have curiousities about many obscure things and my searches often lead me to trying multiple sources to theoretically, hopefully experience the same content, and torrents often sit around for a year or more with me cycling them on and off to try to find a seed (in an unrelated issue I have found that even with a high-end system qBt runs poorly when it has more than ~700 torrents active and that it sadly seems to handle skipping stalled torrents and trying the next one in the queue far worse in Linux(Debian Jessie) than it did under Windows 8 (last time I ran Windows was ~2 years ago now).

Originally created by @teotikalki on GitHub (Aug 22, 2016). I've been experiencing an issue recently where multiple torrents with the same name (at the time of this writing the most recent example was 'Wing Chun') 'get confused'. What happens is that they end up downloading into the same folder (right now that is the /~Incomplete directory inside my root torrent directory) and when one of the torrents finishes, it moves the whole folder out of the incomplete folder, thus breaking the other torrent (the one that didn't finish). I then have to manually sort through the files list, move one set back to my ~Incomplete, and 'Force Recheck'. It seems that it would be fairly simply to implement something like most file managers do where additional torrents with the same name get (1), (2), (etc) appended to them (as a default) and possibly to have the ability to choose the suffix possibly (similar in function to how you can choose a custom append string for incomplete torrents, etc). I doubt that this comes up for many people; my torrenting habits could best be described as 'archivist'. I have curiousities about many obscure things and my searches often lead me to trying multiple sources to theoretically, hopefully experience the same content, and torrents often sit around for a year or more with me cycling them on and off to try to find a seed (in an unrelated issue I have found that even with a high-end system qBt runs poorly when it has more than ~700 torrents active and that it sadly seems to handle skipping stalled torrents and trying the next one in the queue far worse in Linux(Debian Jessie) than it did under Windows 8 (last time I ran Windows was ~2 years ago now).

deekerman

2026-02-21 17:25:23 -05:00

closed this issue
added the
Confirmed bug

Duplicate
labels

deekerman commented

2026-02-21 17:25:26 -05:00

Author

Owner

@thalieht commented on GitHub (Aug 22, 2016):

What version?

@thalieht commented on GitHub (Aug 22, 2016): What version?

deekerman commented

2026-02-21 17:25:29 -05:00

Author

Owner

@teotikalki commented on GitHub (Apr 16, 2017):

It was 3.1.x (Whichever version was in the Debian Jessie repository as of then). I am sorry that I am unable to check for sure; I have since transitioned my system to Debian Stretch (partly inspired by reading that several bugs from 3.1.x are gone in 3.2.x).

@teotikalki commented on GitHub (Apr 16, 2017): It was 3.1.x (Whichever version was in the Debian Jessie repository as of then). I am sorry that I am unable to check for sure; I have since transitioned my system to Debian Stretch (partly inspired by reading that several bugs from 3.1.x are gone in 3.2.x).

deekerman commented

2026-02-21 17:25:29 -05:00

Author

Owner

@thalieht commented on GitHub (Apr 16, 2017):

Since 3.3.5 qbit adds an extra folder (only for incomplete files) to avoid this issue.

@thalieht commented on GitHub (Apr 16, 2017): Since 3.3.5 qbit adds an extra folder (only for incomplete files) to avoid this issue.

deekerman commented

2026-02-21 17:25:29 -05:00

Author

Owner

@brainchild0 commented on GitHub (Jan 5, 2018):

It indeed appears that when multiple torrents have the same name, despite distinct hash codes, qBittorrent places both sets of content in the same directory, leading to collisions. In many cases, the conflicts can go unnoticed if the content of the separate torrents is identical. However, even in this fortunate case, problems arise For example, it appears that if one torrent is deleted with the option selected for "Also delete the files on the hard disk", then the content is removed, leaving the remaining torrent with no content. I have observed this particular problem in version 4.0.3.

Perhaps qBittorrent should enforce a one-to-one relationship between target directory and torrent hash. If a new torrent is added, and the name would lead the application to assign the torrent to a target directory already associated with an existing torrent, then the name of the new directory can be modified, for example to contain a "(2)" suffix. Such solutions are generally used by web browsers while downloading multiple files with the same name.

@brainchild0 commented on GitHub (Jan 5, 2018): It indeed appears that when multiple torrents have the same name, despite distinct hash codes, qBittorrent places both sets of content in the same directory, leading to collisions. In many cases, the conflicts can go unnoticed if the content of the separate torrents is identical. However, even in this fortunate case, problems arise For example, it appears that if one torrent is deleted with the option selected for "Also delete the files on the hard disk", then the content is removed, leaving the remaining torrent with no content. I have observed this particular problem in version 4.0.3. Perhaps qBittorrent should enforce a one-to-one relationship between target directory and torrent hash. If a new torrent is added, and the name would lead the application to assign the torrent to a target directory already associated with an existing torrent, then the name of the new directory can be modified, for example to contain a "(2)" suffix. Such solutions are generally used by web browsers while downloading multiple files with the same name.

deekerman commented

2026-02-21 17:25:29 -05:00

Author

Owner

@ned-martin commented on GitHub (Apr 2, 2019):

I would think the most logical way to handle this would be to treat the directory name as a unique entity that cannot be overwritten, and handle duplicates however the OS handles them.

For example, in Windows, if attempting to create a second folder with the same name as an existing folder, one would expect to end up with two as below:

Folder Name
Folder Name (2)

@ned-martin commented on GitHub (Apr 2, 2019): I would think the most logical way to handle this would be to treat the directory name as a unique entity that cannot be overwritten, and handle duplicates however the OS handles them. For example, in Windows, if attempting to create a second folder with the same name as an existing folder, one would expect to end up with two as below: ``` Folder Name Folder Name (2) ```

deekerman commented

2026-02-21 17:25:29 -05:00

Author

Owner

@ned-martin commented on GitHub (Apr 2, 2019):

Since 3.3.5 qbit adds an extra folder (only for incomplete files) to avoid this issue.

This does not appear to be the case in v4. Torrents with the same name will create directories and files with the same names, and overwrite each other. It seems to be a fairly fundamental issue that I am surprised has not been handled.

@ned-martin commented on GitHub (Apr 2, 2019): > Since 3.3.5 qbit adds an extra folder (only for incomplete files) to avoid this issue. This does not appear to be the case in v4. Torrents with the same name will create directories and files with the same names, and overwrite each other. It seems to be a fairly fundamental issue that I am surprised has not been handled.

deekerman commented

2026-02-21 17:25:29 -05:00

Author

Owner

@teotikalki commented on GitHub (Jun 15, 2019):

@thalieht I'd like to note that I have ALWAYS set a separate 'incomplete' folder. That is irrelevant... downloading multiple torrents with the same name causes a problem WHEN MORE THAN ONE ARE INCOMPLETE.

@teotikalki commented on GitHub (Jun 15, 2019): @thalieht I'd like to note that I have ALWAYS set a separate 'incomplete' folder. That is irrelevant... downloading multiple torrents with the same name causes a problem WHEN MORE THAN ONE ARE INCOMPLETE.

deekerman commented

2026-02-21 17:25:29 -05:00

Author

Owner

@AnnanFay commented on GitHub (Jul 6, 2019):

When adding a new torrent which conflicts with an existing folder name it should warn you and ask what you want to do.

WARNING: This download will overwrite local files. What do you want to do?
[Overwrite] [Rename existing] [Rename new] [Cancel]

Is there a good local fix to this issue? Right now the only solution I have found is to manually enable "Create subfolder" and keep an eye out for folder names which match previous ones. If you spot them before they are added you can rename the destination folder before it becomes an issue.

@AnnanFay commented on GitHub (Jul 6, 2019): When adding a new torrent which conflicts with an existing folder name it should warn you and ask what you want to do. > WARNING: This download will overwrite local files. What do you want to do? > [Overwrite] [Rename existing] [Rename new] [Cancel] Is there a good local fix to this issue? Right now the only solution I have found is to manually enable "Create subfolder" and keep an eye out for folder names which match previous ones. *If* you spot them before they are added you can rename the destination folder before it becomes an issue.

deekerman commented

2026-02-21 17:25:29 -05:00

Author

Owner

@brainchild0 commented on GitHub (Jul 6, 2019):

Suspending an operation to await user feedback is not always the best course, especially for batch or scripted operations. It may be wiser if the application follows a particular default behavior. Renaming, and similar operations, can be invoked later, if desired.

Edit: Once someone implements an automatic naming scheme, I think this issue could be closed. Further functionality, such as an option to prompt the user for conflict resolution, as @teotikalki suggests, could be requested in separate feature issues. (I do think any such prompt should be based on a configuration option, however, as oppose to being unconditional, for reasons of facilitating automatic and batch operations.)

@brainchild0 commented on GitHub (Jul 6, 2019): Suspending an operation to await user feedback is not always the best course, especially for batch or scripted operations. It may be wiser if the application follows a particular default behavior. Renaming, and similar operations, can be invoked later, if desired. **Edit:** Once someone implements an automatic naming scheme, I think this issue could be closed. Further functionality, such as an option to prompt the user for conflict resolution, as @teotikalki suggests, could be requested in separate feature issues. (I do think any such prompt should be based on a configuration option, however, as oppose to being unconditional, for reasons of facilitating automatic and batch operations.)

deekerman commented

2026-02-21 17:25:29 -05:00

Author

Owner

@brainchild0 commented on GitHub (Aug 3, 2019):

A few further thoughts:

Some users are reporting a resolution in 4.X versions, whereas I and others are not. Can we elucidate the discrepancy? Has someone added a feature to resolve this behavior, and if so, why are many users not experiencing it?
One way to make the probability of collision very close to zero is to include, in all cases, part of the hash code in the directory name, for example, the last six hexadecimal digits, following a space and surrounded by a parenthesis set.
Many torrents are derived from previous torrents, and contain largely the same content. It would be interesting to consider a way to use hard links to avoid writing identical files in different locations on the same file system.

@brainchild0 commented on GitHub (Aug 3, 2019): A few further thoughts: 1. Some users are reporting a resolution in 4.X versions, whereas I and others are not. Can we elucidate the discrepancy? Has someone added a feature to resolve this behavior, and if so, why are many users not experiencing it? 2. One way to make the probability of collision very close to zero is to include, in all cases, part of the hash code in the directory name, for example, the last six hexadecimal digits, following a space and surrounded by a parenthesis set. 3. Many torrents are derived from previous torrents, and contain largely the same content. It would be interesting to consider a way to use hard links to avoid writing identical files in different locations on the same file system.

deekerman commented

2026-02-21 17:25:29 -05:00

Author

Owner

@ned-martin commented on GitHub (Aug 4, 2019):

I don't understand why this is complicated?

Do what every other program does - if there's a "package" with the same name already on the file system, append a number to the new one. Ideally update the UI in some way to indicate this.

You end up with:
Linux ISO
Linux ISO (1)
Linux ISO (2)
and so forth.

It's how every other software I know works, and seems really simple to implement.

@ned-martin commented on GitHub (Aug 4, 2019): I don't understand why this is complicated? Do what every other program does - if there's a "package" with the same name already on the file system, append a number to the new one. Ideally update the UI in some way to indicate this. You end up with: Linux ISO Linux ISO (1) Linux ISO (2) and so forth. It's how every other software I know works, and seems really simple to implement.

deekerman commented

2026-02-21 17:25:29 -05:00

Author

Owner

@dausruddin commented on GitHub (May 31, 2020):

Bumping this. I had the same issue just now where both torrents with hundreds of files ended up in the same folder. Luckily both have different file name in them, so I just need to set location 1 of the torrent to another location and it moved them fine.

But this won't be the same if both torrent have some same file name.

@dausruddin commented on GitHub (May 31, 2020): Bumping this. I had the same issue just now where both torrents with hundreds of files ended up in the same folder. Luckily both have different file name in them, so I just need to set location 1 of the torrent to another location and it moved them fine. But this won't be the same if both torrent have some same file name.

deekerman commented

2026-02-21 17:25:29 -05:00

Author

Owner

@thalieht commented on GitHub (Sep 13, 2020):

Duplicate of #127

@thalieht commented on GitHub (Sep 13, 2020): Duplicate of #127