starred/qBittorrent

Fork 0

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

qB corrupts files when there are two torrents with same filenames but different hashes #8812

New issue

Open

opened 2026-02-21 19:49:36 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-21 19:49:36 -05:00

Owner

Originally created by @nick-s-b on GitHub (Jun 14, 2019).

Please provide the following information

qBittorrent version and Operating System

Linux, qbittorrent 4.1.6

If on linux, libtorrent and Qt version

libtorrent-rasterbar 1:1.1.12
qt5-base 5.12.3-2

What is the problem

If you add two torrents, with different hashes but same filenames, qB will not create different folders for them and will just happily write data to the same file even if the two torrents are not the same or of the same size. Even if the files are the same, qB will not reconstruct the file correctly.

What is the expected behavior

If there are multiple torrents with different hashes but same filenames, create different folders for them

Steps to reproduce

Create two torrent files that have the same folder structure but different hashes and try to download them at the same time. qB will happily start both torrents but will write data to the same file and you'll end up with a corrupted file.

Originally created by @nick-s-b on GitHub (Jun 14, 2019). **Please provide the following information** ### qBittorrent version and Operating System Linux, qbittorrent 4.1.6 ### If on linux, libtorrent and Qt version libtorrent-rasterbar 1:1.1.12 qt5-base 5.12.3-2 ### What is the problem If you add two torrents, with different hashes but same filenames, qB will not create different folders for them and will just happily write data to the same file even if the two torrents are not the same or of the same size. Even if the files are the same, qB will not reconstruct the file correctly. ### What is the expected behavior If there are multiple torrents with different hashes but same filenames, create different folders for them ### Steps to reproduce Create two torrent files that have the same folder structure but different hashes and try to download them at the same time. qB will happily start both torrents but will write data to the same file and you'll end up with a corrupted file.

deekerman added the

Confirmed bug

Core

Data loss

labels

2026-02-21 19:49:36 -05:00

deekerman commented

2026-02-21 19:49:38 -05:00

Author

Owner

@a-raccoon commented on GitHub (Jun 20, 2019):

Yes. QB should automatically append a number to the end of duplicate file or folder names when the file or folder are not expected (newly added / completed-moved torrent).

@a-raccoon commented on GitHub (Jun 20, 2019): Yes. QB should automatically append a number to the end of duplicate file or folder names when the file or folder are not expected (newly added / completed-moved torrent).

deekerman commented

2026-02-21 19:49:41 -05:00

Author

Owner

@archfrog commented on GitHub (Apr 5, 2020):

I seem to often run into the case where two queued torrents use the same root folder name. It would be so nifty if qBittorrent automatically appended a number at the end of the second torrent's root folder name.

For instance, given two torrents A and B, both storing their stuff in C, qBittorrent should create two folders named C and C1 (or something like it).

So whenever a new torrent is added for download, qBittorrent should check if there's already an existing folder with that name and then automatically rename the newest folder.

@archfrog commented on GitHub (Apr 5, 2020): I seem to often run into the case where two queued torrents use the same root folder name. It would be so nifty if qBittorrent automatically appended a number at the end of the second torrent's root folder name. For instance, given two torrents A and B, both storing their stuff in C, qBittorrent should create two folders named C and C1 (or something like it). So whenever a new torrent is added for download, qBittorrent should check if there's already an existing *folder* with that name and then automatically rename the newest folder.

deekerman commented

2026-02-21 19:49:41 -05:00

Author

Owner

@zecanard commented on GitHub (Apr 5, 2020):

qBittorrent should check if there's already an existing folder with that name

As per @a-raccoon, this also affects single-file torrents (which get stored at the root of the Incomplete folder), not just torrents that create identical folders. So a fix would need to account for both scenarios.

@zecanard commented on GitHub (Apr 5, 2020): > qBittorrent should check if there's already an existing _folder_ with that name As per @a-raccoon, this also affects single-file torrents (which get stored at the root of the Incomplete folder), not just torrents that create identical folders. So a fix would need to account for both scenarios.

deekerman commented

2026-02-21 19:49:41 -05:00

Author

Owner

@a-raccoon commented on GitHub (Apr 5, 2020):

And we should also take into account, if not already, all other scenarios where file folder or name collisions occur, such as when moving from the Incomplete/Temp folder to the Completed/Category destination folder. Or when moving back from the Completed/Category folder into the Incomplete/Temp folder after a Force Recheck identifies a corruption, missing file, etc. And also when adding or removing the .!qB part_file extension above.

All file/folder move and rename operations risk the potential for collision and dueling write corruption.

@a-raccoon commented on GitHub (Apr 5, 2020): And we should also take into account, if not already, all other scenarios where file folder or name collisions occur, such as when moving from the Incomplete/Temp folder to the Completed/Category destination folder. Or when moving back from the Completed/Category folder into the Incomplete/Temp folder after a Force Recheck identifies a corruption, missing file, etc. And also when adding or removing the .!qB part_file extension above. All file/folder move and rename operations risk the potential for collision and dueling write corruption.

deekerman commented

2026-02-21 19:49:41 -05:00

Author

Owner

@tristanleboss commented on GitHub (Sep 9, 2022):

Got this exact same problem a lot of times. When you add torrents from magnet links, you don't know their contents. So, you have no way to plan different save path. And at the end, if the torrents have contents with same names, it's an ugly mess.

@tristanleboss commented on GitHub (Sep 9, 2022): Got this exact same problem a lot of times. When you add torrents from magnet links, you don't know their contents. So, you have no way to plan different save path. And at the end, if the torrents have contents with same names, it's an ugly mess.

deekerman commented

2026-02-21 19:49:41 -05:00

Author

Owner

@dftf-stu commented on GitHub (Dec 4, 2024):

Yes, for example, you might be trying to download an obscure album:
🕑The Examples - Best of The Examples (2003) 320kbps MP3 ... gathering metadata
🕑The Examples - Best of The Examples (2003) 320kbps MP3 ... gathering metadata

An hour later, of whatever, they've finally both started...
🔽The Examples - Best of The Examples (2003) 320kbps MP3 ... downloading
🔽The Examples - Best of The Examples (2003) 320kbps MP3 ... downloading

...but they are both saving into the same folder 🙃:
C > Users > dftf-stu > Downloads > Torrents > The Examples - Best of The Examples (2003) 320kbps MP3

Which means they are endlessly overwriting each-others' files, and once they verify at the end, will always
say "error: file hashes do not match" and try again, in an endless-loop!

An easy fix to this would be to simply put some characters from the start or end of the torrent hash into
each folder name, for example:
📂The Examples - Best of The Examples (2003) 320kbps MP3 c1d7f6ab
📂The Examples - Best of The Examples (2003) 320kbps MP3 d21c77f9

It amazes me how no torrent app I've ever used -- this one, Transmission or Flud (Android) -- do this. 🤷🏻‍♂️

@dftf-stu commented on GitHub (Dec 4, 2024): Yes, for example, you might be trying to download an obscure album: 🕑The Examples - Best of The Examples (2003) 320kbps MP3 ... gathering metadata 🕑The Examples - Best of The Examples (2003) 320kbps MP3 ... gathering metadata An hour later, of whatever, they've finally both started... 🔽The Examples - Best of The Examples (2003) 320kbps MP3 ... downloading 🔽The Examples - Best of The Examples (2003) 320kbps MP3 ... downloading ...but they are both saving into the same folder 🙃: C > Users > dftf-stu > Downloads > Torrents > The Examples - Best of The Examples (2003) 320kbps MP3 Which means they are endlessly overwriting each-others' files, and once they verify at the end, will always say "error: file hashes do not match" and try again, in an endless-loop! An easy fix to this would be to simply put some characters from the start or end of the torrent hash into each folder name, for example: 📂The Examples - Best of The Examples (2003) 320kbps MP3 c1d7f6ab 📂The Examples - Best of The Examples (2003) 320kbps MP3 d21c77f9 It amazes me how no torrent app I've ever used -- this one, Transmission or Flud (Android) -- do this. 🤷🏻‍♂️