mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
Never silently overwrite existing files #112
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#112
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Changaco on GitHub (Sep 27, 2012).
qBittorrent should never overwrite existing files without explicit confirmation from the user. Moreover, it should always checksum them and keep them if they match the torrent.
@jklense commented on GitHub (Sep 30, 2012):
second this
@Belove0 commented on GitHub (Apr 10, 2013):
yes :)
I believe uTorrent puts torrents in a paused state with a message suggesting a recheck in cases like this.
@cbj4074 commented on GitHub (May 5, 2013):
The importance of this premise cannot be overstated. I love qBittorrent, but I must say, overwriting files without user confirmation is a major problem with this client. I've had to re-download several GB files as a result of this behavior.
If I start qBittorrent without my download drive connected, all completed torrents whose destinations are on that drive start in a "Paused" state, which is fine. The problem is when I notice this and then mount the target volume on which the downloaded files already exist, and then click "Play" for each torrent, and qBittorrent proceeds to pave-over the existing files without warning!
Is there some workaround for this, now that I know what's happening? Do I need to right-click and choose "Force recheck" in this scenario, instead of clicking "Play"?
@sledgehammer999 commented on GitHub (May 5, 2013):
I am almost certain that doing a force recheck before clicking "play" will not overwrite the files.
For all the others. I agree that this is a serious problem and needs fixing. The sad part is that we don't have much time to devote. I suspect to fix this bug you need to touch the code in several places and probably add more code. This isn't a simple one-liner bug unfortunately.
For the time being, I suggest doing a force recheck when a torrent is paused because of an error.
Also, some situtations aren't handled correctly by libtorrent either. For example:
@sledgehammer999 commented on GitHub (May 5, 2013):
I made a feature request upstream for the last "bug": https://code.google.com/p/libtorrent/issues/detail?id=473
Also appending label "waiting API implementation", because it partially involves this bug.
@jackpoc commented on GitHub (Jun 17, 2013):
Just to confirm that uTorrent doesn't have this problem. qBittorrent caused me severe headaches because of this.
@Soukyuu commented on GitHub (Apr 14, 2014):
The issue is listed as "fixed" on the libtorrent side now (see link posted by sledgehammer999), any chance of incorporating this into qBittorrent? Overwriting of files was the reason for me to go back to µtorrent, as I'm not on a fast connection to be able to easily recover from losing gigabytes of data.
@sirinath commented on GitHub (May 11, 2014):
Problem is when you some times start the client after a crash some times the size is not recorder and data is re downloaded.
@sirinath commented on GitHub (May 17, 2014):
When you use the extension for part downloads sometimes the extension is not used and in force rechecks the files without the incomplete extension are overridden.
In competed files in a multi part download the extension is some times removed when a file is completed. Sometime the completed portion is not detected and re created with the extension for incomplete downloads.
@Soukyuu commented on GitHub (Jul 27, 2014):
This should be treated as a critical bug. What good is a torrent client that destroys data meant to be distributed? There isn't even an error or anything when adding a torrent that already finished downloading (for example, with a different client).
At least add a "one-liner" workaround which sets the torrent into error state if files with same name is detected in the directory where the completed files land. Pretty please?
Sticking with µtorrent for now, and god knows that's not optimal on linux...
@chrishirst commented on GitHub (Jul 28, 2014):
uTorrent does NOT use the libtorrent or libtorrent-rasterbar BitTorrent protocol engine so is unaffected by the issue
@Soukyuu commented on GitHub (Jul 28, 2014):
Yes, obviously it doesn't use libtorrent, that's not the point here. The point is I have to resort to using a wine program because the rest of the linux clients either don't offer it's functionality or eat my files.
I wish I could fix that myself, but looking at the code I'm totally lost in it.
@chrishirst commented on GitHub (Jul 28, 2014):
But it IS the point, the 'bug', 'problem', 'issue' IS in the libtorrent library, so it is NOT something that can be 'fixed' in the source code of qBittorrent. No amount of complaining or cajoling (though bribery will be welcomed) here or at the support forum will get this 'fixed'.,It is plainly, simply and wholly outside the control of qBT developers.
@Soukyuu commented on GitHub (Jul 28, 2014):
I suggest you re-read the messages. The issue @sledgehammer999 has reported to the libtorrent devs has been fixed. There is no issue with libtorrent anymore, it was fixed. Libtorrent now offers functionality to check for existing files. So no, the paving over files issue is not outside of developer's control. Not anymore.
@sledgehammer999 commented on GitHub (Jul 28, 2014):
Just so you know, that feature was implemented in the libtorrent 1.0.x series which was recently released. I don't think any distro has packaged it yet. So even if I put code inside qbt to utilize that it would be meaningless for linux users atm.
@Soukyuu commented on GitHub (Jul 28, 2014):
I'm on arch, so I have to get qbt from AUR anyway, might as well pull libtorrent-git or libtorrent-rasterbar-svn for it as well. I think adding the code to qbt might also be a good incentive for distros to update libtorrent.
@sledgehammer999 commented on GitHub (Jul 28, 2014):
You'll need to recompile against 1.0.x too...
@Soukyuu commented on GitHub (Jul 28, 2014):
AUR is arch's user repository, which hosts source packages to be built on target system. Means installing qbt from AUR will make me build libtorrent 1.0.x first, then build qbt against the built libtorrent version. The packaging rules have that covered.
@Soukyuu commented on GitHub (Aug 5, 2014):
By the way, I'm not sure how "separate" the RSS downloader is in this scenario, but the last time I lost data was because it matched an entry I already had downloaded with another client, and overwrote each file without going into the error state as it (apparently) does when you add a torrent manually.
@Soukyuu commented on GitHub (Aug 16, 2014):
I don't know if it helps, but I tried to sum up the checks that have to be implemented for the two scenarios:
-> if yes, start recheck
-> if yes, start recheck
-> else allocate file (if set)
@sledgehammer999 commented on GitHub (Aug 16, 2014):
Yes. A flowchart helps when implementing the code. It helps to not forget things.
@maxrd2 commented on GitHub (Dec 22, 2014):
Was any work already done on this? If not would like to look into it a submit a pull request at some point
@sledgehammer999 commented on GitHub (Dec 26, 2014):
I am actively working on this. And probably no one else. So you can look into it if you want.
@ghost commented on GitHub (Apr 19, 2017):
This is still a problem right? Lost a 200MB file yesterday.
@sealj553 commented on GitHub (Jan 21, 2018):
Just lost over 10,000 files due to this error. Can't believe this hadn't been fixed yet.
@Chematronix commented on GitHub (Mar 29, 2018):
qBit also overwrites any changes you've made to already downloaded files without notice. Ouch.
@EraYaN commented on GitHub (Oct 20, 2018):
This just wiped out quite some files, qBittorrent moves existing files back to the main Downloads folder (from Downloads Finished). Some will properly recheck, but some are full of zeros and overwritten.
qBittorrent was started without the storage medium connected (dodgy Mellanox NIC drivers), but normally a quit and a restart fixes and reloads all torrents, well this time, it spend time writing zeros to files it seems.
@nathanielcwm commented on GitHub (Jul 13, 2019):
I made a torrent and some files haven't been fully transmitted to the swarm and qbittorent overwrote them ;(
@TomArrow commented on GitHub (Oct 3, 2019):
Situation: I had two folders on my hard drive, unsure which one was the completed one. I pointed the torrent on the uncompleted one by accident. It checked to around 10%.
Then I pointed it to the completed one. Guess what happened? Qbit overwrote the completed files with the 10% files.
This is absolutely horrendous and unacceptable. These are files that I've waited two years for a seeder for! It's sheer luck that I still have a backup of them on my seedbox.
It's unbelievable that this doesn't get fixed. This should be priority number 1. Whoever programmed this had zero respect or consideration for the final user's data.
Same issue as here: https://github.com/qbittorrent/qBittorrent/issues/8758
That issue was well-explained and actually got the "data-loss" tag to show how important it is but got closed because "muh duplicate" and this badly formulated very abstract issue stays up as the original.
Again, UN-FUCKING-BELIEVABLE.
@HDVinnie commented on GitHub (Oct 3, 2019):
Wait so this has been a issue for 7+ years......wtf.
@tyestor commented on GitHub (Nov 19, 2019):
Is this ever going to be fixed? You'd think this issue would be number 1 priority. Using an external HDD with Qbittorrent is pointless until it is.
@ghost commented on GitHub (Oct 12, 2020):
Guess I am gonna return to my utorrent 2.2.1. Not able to sort files by folder, but able to automatically recheck finished downloads.
It is "hilarious" to stumble upon 8 year old problem. One critical problem that ruins entire amazing project. It's almost like building 5th gen fighter that is unable to carry missiles.
@sakkamade commented on GitHub (Oct 12, 2020):
Well, this problem is pretty common. I personally encountered many torrents with this problem:
There's exists a lot of torrents which contains file/files with the same filename(s)
and the same extension(s),but content of the file(s) is different.
I'm asking for function which will
check sizesof the file(s) in new torrent and existing one,or
check filenames + hash(or something else), and if its mismatch with already present file(s),qbittorrent must open "adding-torrent window" with warning message:
@sledgehammer999 @glassez @Chocobo1 @FranciscoPombal, Please, move this issue higher in your priority-lists.
@slrslr commented on GitHub (Jun 14, 2021):
Just lost another files due to this issue. 😭
@kenshinnmt commented on GitHub (Apr 15, 2022):
I want to overwrite the content in the specified existing directory with qbittorent, how can I do that?
@mzso commented on GitHub (Apr 15, 2022):
@kenshinnmt commented on 2022. ápr. 15. 11:27 CEST:
Matching files are automatically checked and overwritten as needed when you start a torrent.
@kenshinnmt commented on GitHub (Apr 15, 2022):
In my case, qbittorent does not overwrite, I want to override to update content but can't.
When I start adding torrent files, the metadata shows the new content, but when it's done, the old content is still there, nothing has changed.
@mzso commented on GitHub (Apr 15, 2022):
@kenshinnmt commented on 2022. ápr. 15. 11:58 CEST:
Then there's nothing to overwrite because the files are different.
@kenshinnmt commented on GitHub (Apr 15, 2022):
In my case, the file content is different.
File A.exe, size 313kb, downloaded with qbittorent 1st time, everything works perfectly.
Then I edited the A.exe file mentioned above, and the new size is 115kb.
I create a new torrent file, the metadata before starting to download the file shows that the size of A.exe is 115kb, but after qbittorent has finished downloading, the torrent status is 100%, seeding, file A .exe is still 313kb, it's the old file.
@mzso commented on GitHub (Apr 15, 2022):
@kenshinnmt
What do you mean "I create a new torrent file", how is creating a torrent file relevant? What the hell are you doing?
@kenshinnmt commented on GitHub (Apr 15, 2022):
I create torrents to share my files with other remote computers.
As I said above, I used qbittorent to create torrent files, used qbittorent to download, and the first time everything worked fine.
The second time, I need to edit the content, but still the A.exe name, then continue to create the torrent file, and share it to the remote computer, this time qbittorent does not overwrite the A.exe file.
@stdedos commented on GitHub (Apr 15, 2022):
It really feels to me that you are missing the point of this ticket.
You might want to open a new ticket and plead your case separately
@kenshinnmt commented on GitHub (Apr 15, 2022):
https://github.com/qbittorrent/qBittorrent/issues/16881
I tried to open a ticket at this link
I would like to see more similar cases about this error
@ZaCloud commented on GitHub (Sep 27, 2022):
Happy 10 year anniversary to this crippling issue, STILL not even being listed as being worked on!
...Wooooo!
........ 😑
@ooddaa commented on GitHub (Oct 4, 2022):
it's not a bug, it's a feature 😹
re-downloading a bunch of stuff thanks to this.
@cxjiek commented on GitHub (Oct 7, 2022):
Was using deluge and utorrent 2.2.1, never had this issue
Just started using qbittorrent, encountered this issue.
@mzso commented on GitHub (Oct 11, 2022):
What is the problem actually, because there's exactly nothing useful in the opening post.
@slrslr commented on GitHub (Oct 12, 2022):
@mzso
Please search for word "referenced" on this page and click the links. Numerous issues was closed in favor of this one.
@Arturoe1 commented on GitHub (Apr 22, 2023):
Issue is present currently, i get a Torrent which shares the same path and most of the files. It is a collection which the owner of the torrent keeps adding files and updating the torrent instead re-sharing all the content in a new torrent.
Expected behavior is after finishing the checksum qBit can handle the files: Downloading the missing / failed ones and sharing the others.
Currently qBit marks the torrents as permanently "moving" and does not download / upload properly. This only happens with qBit as other torrent clients can handle this properly (by pausing one of the torrents or doing as expected)
@sirinath commented on GitHub (Apr 22, 2023):
Maybe you need to open a new issue for this @Arturoe1
@kesumin commented on GitHub (Jun 21, 2023):
Bumping this issue? Although this thread has been open for more than a decade there hasn't been a fix? Possibly a checksum associated with the torrent stored locally might pose as a simple workaround, especially for my situation.
I have set all torrents to download locally and moved to a local network storage location. This server is taken down moderately frequently for matinence and the machine running qbittorrent isn't always shut down with the server.
@StrangePeanut commented on GitHub (Jun 21, 2023):
I can't believe that it's already been 11 years. Originally this issue drove me absolutely mad as one of the foreign trackers I was on would repeatedly offer torrents whose folders/files used existing names but different contents. I ended up using a different client at the time. Fortunately they have since stopped that ridiculous practice, but it's one reason why this could be a real issue in some rare scenarios.
@seniorm0ment commented on GitHub (Jul 6, 2023):
@kesumin
This. I lost so many files recently because of this. Same setup, mapped to network storage. Qbitorrent didn't shut down with the server because it's on a separate machine. It looks like qbit deleted the files, and tried to redownload them. A lot of the trackers don't even actually work anymore. So I have no way of getting the files back.
Absolutely insane. This should be a top priority issue.
@rctlmk commented on GitHub (Nov 11, 2023):
Bump. I still would like to see this feature implemented.
@mzso commented on GitHub (Nov 12, 2023):
@seniorm0ment
You guys might need to rethink your setup. Writing the matching files in question is normal behavior.
@StrangePeanut Does this actually happen? Formerly I donwloaded stuff on storage that was removed the later re-added, but don't remember re-downloads, I did get data loss with the ".unwanted" folder clusterF.
@seniorm0ment commented on GitHub (Nov 12, 2023):
How else would I set it up? The files are stored on my server.
If qbit realizes it can't find the storage path, then why does it try to redownload? Also it was redownloading when the server came back up, so the storage path was there. But it just started overwriting or something.
Do out expect me to have duplicates of all the files, just so one folder can be used exclusively for seeding? If it was 30gb that's one thing, but when you have terabytes of different stuff.
@mzso commented on GitHub (Nov 12, 2023):
@seniorm0ment
Not knowing any details, you might be able to run QB run on the server and download it there directly. Access it via WebUI if nothing else.
Maybe don't set QB to move automatically the files there, move it manually, only if you really need it there. Such things.
@sabaal commented on GitHub (Nov 10, 2024):
REALLY？Just add some (1) after the name
@glassez commented on GitHub (Nov 11, 2024):
It seems that this topic has finally turned into trash of different kind of (often weakly related) issues some of them fixed since then.
If anyone is hoping for some kind of progress, then I would create new Issues separately for a specific cases that are still relevant in the current qBittorrent version.
@xavier2k6 commented on GitHub (Nov 11, 2024):
This ticket has been closed.
Closure Reason: being "out-of-date", and thus either most likely resolved in recent versions or no longer applicable.
If you experience the reported problem or similar in the latest version, please open a new issue report with the requested information in the issue template.
Due to the changes made to the qBittorrent code and its dependencies over time, the exact cause of your problem could be totally different than the original one, despite the visible symptoms of the bug being similar.
Thus, providing relevant updated information is crucial to find and fix the root cause of a recurrent problem or regression.
A new issue report with relevant updated data gathered from the latest version is preferable to necroing an old report with a comment like "still happens in version x.y.z", even if you think the bug is the same, or suspect of a regression.
Thank you for your contribution(s).