starred/qBittorrent

Fork 0

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

[critical bug] qbittorrent deletes partitions! #14681

New issue

Open

opened 2026-02-22 01:19:14 -05:00 by deekerman · 13 comments

deekerman commented

2026-02-22 01:19:14 -05:00

Owner

Originally created by @jackffmm on GitHub (Jun 6, 2023).

qBittorrent & operating system versions

qbittorrent all versions.
All OSes

What is the problem?

When shutting down the device qbt may cause file system errors that lead to lose files or partitions. And let me tell you, this is not nice. This happened to me, on both, windows and linux.

Steps to reproduce

Turn off the pc while qbt is running.

Additional context

This may happend even if you remember to exit qbt and then shut down.

If you can't stop the downloading of the files quickly(I dont think that you cant), at least show a dialog untill qbt is really closed.
At the moment the only way to know when qbt is done, its to to see when the tray icon disappear on win, or when the empty space disappear on linux.

But a better solution would be to quickly close the operations.

Log(s) & preferences file(s)

No response

Originally created by @jackffmm on GitHub (Jun 6, 2023). ### qBittorrent & operating system versions qbittorrent all versions. All OSes ### What is the problem? When shutting down the device qbt may cause file system errors that lead to lose files or partitions. And let me tell you, this is not nice. This happened to me, on both, windows and linux. ### Steps to reproduce Turn off the pc while qbt is running. ### Additional context This may happend even if you remember to exit qbt and then shut down. If you can't stop the downloading of the files quickly(I dont think that you cant), at least show a dialog untill qbt is really closed. At the moment the only way to know when qbt is done, its to to see when the tray icon disappear on win, or when the empty space disappear on linux. But a better solution would be to quickly close the operations. ### Log(s) & preferences file(s) _No response_

deekerman added the

Data loss

label

2026-02-22 01:19:14 -05:00

deekerman commented

2026-02-22 01:19:19 -05:00

Author

Owner

@Vort commented on GitHub (Jun 7, 2023):

Do you use FAT filesystem on Windows?

@Vort commented on GitHub (Jun 7, 2023): Do you use FAT filesystem on Windows?

deekerman commented

2026-02-22 01:19:26 -05:00

Author

Owner

@Saarsk commented on GitHub (Jun 7, 2023):

If qBittorrent causes this on both Windows and Linux it's an issue beyond filesystems, right? Though it probably wouldn't hurt to add additional info like file systems and distros still. And hardware specifications.

By "all versions" what do you mean specifically? Which version have you had installed AND with this happening? :) It's very unlikely that all versions have this issue.

Anecdote: I've had my PC crash with qBittorrent running several times on Fedora (Btrfs). Currently have 4.5.2 installed, but have had it crash with earlier versions as well without issues regarding filesystems breaking. There is a driver issue on my specific laptop causing freezes so I've had to force shutdown many times with qBittorrent running. Either this is a problem specific to your setup or it needs investigation to figure out what exactly causes it. The devs need clues and information in order to fix it also.

It would be interesting if you were able to reproduce this on a fresh install and only qBittorrent installed and running. Also, if you could test with a different storage drive (to rule out hardware).

(Not) a random question, do you have a Samsung 980 series SSD by any chance? If you do, which firmware version it is running?

@Saarsk commented on GitHub (Jun 7, 2023): If qBittorrent causes this on both Windows and Linux it's an issue beyond filesystems, right? Though it probably wouldn't hurt to add additional info like file systems and distros still. And hardware specifications. By "all versions" what do you mean specifically? Which version have you had installed AND with this happening? :) It's very unlikely that all versions have this issue. Anecdote: I've had my PC crash with qBittorrent running several times on Fedora (Btrfs). Currently have 4.5.2 installed, but have had it crash with earlier versions as well without issues regarding filesystems breaking. There is a driver issue on my specific laptop causing freezes so I've had to force shutdown many times with qBittorrent running. Either this is a problem specific to your setup or it needs investigation to figure out what exactly causes it. The devs need clues and information in order to fix it also. It would be interesting if you were able to reproduce this on a fresh install and only qBittorrent installed and running. Also, if you could test with a different storage drive (to rule out hardware). (Not) a random question, do you have a Samsung 980 series SSD by any chance? If you do, which firmware version it is running?

deekerman commented

2026-02-22 01:19:26 -05:00

Author

Owner

@Vort commented on GitHub (Jun 7, 2023):

If qBittorrent causes this on both Windows and Linux it's an issue beyond filesystems, right?

The thing is partitions are entities abstracted by operating system.
It should not be possible except for rare cases to damage them with user mode software.

However if file system or operating system are unreliable, then any action can trigger problem.
That's the case for FAT file system - it may lose user data just because it is poorly designed.
Theoretically same thing may happen for Linux file systems. However, I know such example only for Windows.

@Vort commented on GitHub (Jun 7, 2023): > If qBittorrent causes this on both Windows and Linux it's an issue beyond filesystems, right? The thing is partitions are entities abstracted by operating system. It should not be possible except for rare cases to damage them with user mode software. However if file system or operating system are unreliable, then any action can trigger problem. That's the case for FAT file system - it may lose user data just because it is poorly designed. Theoretically same thing may happen for Linux file systems. However, I know such example only for Windows.

deekerman commented

2026-02-22 01:19:26 -05:00

Author

Owner

@Saarsk commented on GitHub (Jun 7, 2023):

The thing is partitions are entities abstracted by operating system. It should not be possible except for rare cases to damage them with user mode software.

However if file system or operating system are unreliable, then any action can trigger problem. That's the case for FAT file system - it may loose user data just because it is poorly designed. Theoretically same thing may happen for Linux file systems. However, I know such example only for Windows.

Yeah, this seems strange. I wanted to give the benefit of the doubt.

File corruption caused by a program doesn't seem far-fetched to me, but messing up a partition? O.o?

The reason I mentioned Samsung 980 variant SSDs is that there have been serious firmware problems with that generation. It could've been a filesystem thing, but unlikely considering it's (likely) across different filesystems.

Unless, he has dual boot configuration and access the same data partition on both Windows and Linux. Windows isn't exactly known for having broad file system support. And it's definitely not known for being graceful or careful with other operating system partitions/bootloaders.

@Saarsk commented on GitHub (Jun 7, 2023): > The thing is partitions are entities abstracted by operating system. It should not be possible except for rare cases to damage them with user mode software. > > However if file system or operating system are unreliable, then any action can trigger problem. That's the case for FAT file system - it may loose user data just because it is poorly designed. Theoretically same thing may happen for Linux file systems. However, I know such example only for Windows. Yeah, this seems strange. I wanted to give the benefit of the doubt. File corruption caused by a program doesn't seem far-fetched to me, but messing up a partition? O.o? The reason I mentioned Samsung 980 variant SSDs is that there have been serious firmware problems with that generation. It could've been a filesystem thing, but unlikely considering it's (likely) across different filesystems. Unless, he has dual boot configuration and access the same data partition on both Windows and Linux. Windows isn't exactly known for having broad file system support. And it's definitely not known for being graceful or careful with other operating system partitions/bootloaders.

deekerman commented

2026-02-22 01:19:27 -05:00

Author

Owner

@Vort commented on GitHub (Jun 7, 2023):

I agree, it may be also hardware problem.

@Vort commented on GitHub (Jun 7, 2023): I agree, it may be also hardware problem.

deekerman commented

2026-02-22 01:19:27 -05:00

Author

Owner

@jackffmm commented on GitHub (Jun 7, 2023):

More info: win 8 and artix, ntfs and ext4. its a hard disk. I've heard of other people had similar problems with qbt anyway.

@Saarsk its not beyond the filesystem, its before the fs. If im not wrong Btrfs is specialized to recover fs errors.

Its a fact that qbt stays open half minute after you quit and the user is not notified, this is simply wrong. Now I dont know why it stays open but when the close signial is recieved can't it close the files immediatly ?

Anyway at least a dialog untill qbt really quit, must be done.

@jackffmm commented on GitHub (Jun 7, 2023): More info: win 8 and artix, ntfs and ext4. its a hard disk. I've heard of other people had similar problems with qbt anyway. @Saarsk its not beyond the filesystem, its before the fs. If im not wrong Btrfs is specialized to recover fs errors. Its a fact that qbt stays open half minute after you quit and the user is not notified, this is simply wrong. Now I dont know why it stays open but when the close signial is recieved can't it close the files immediatly ? Anyway at least a dialog untill qbt really quit, must be done.

deekerman commented

2026-02-22 01:19:27 -05:00

Author

Owner

@haidar47x commented on GitHub (Jun 7, 2023):

Really? 🤕

@haidar47x commented on GitHub (Jun 7, 2023): Really? 🤕

deekerman commented

2026-02-22 01:19:27 -05:00

Author

Owner

@jackffmm commented on GitHub (Jun 8, 2023):

Really!

@jackffmm commented on GitHub (Jun 8, 2023): Really!

deekerman commented

2026-02-22 01:19:27 -05:00

Author

Owner

@ghost commented on GitHub (Jun 12, 2023):

Maybe “Shutdown Anyway” is turned on. If AutoEndTasks is set to 1, your PC shut down is forced. I don't like this registry setting. Google it! It's a guess. I'm not a PC expert.

@ghost commented on GitHub (Jun 12, 2023): Maybe “Shutdown Anyway” is turned on. If AutoEndTasks is set to 1, your PC shut down is forced. I don't like this registry setting. Google it! It's a guess. I'm not a PC expert.

deekerman commented

2026-02-22 01:19:27 -05:00

Author

Owner

@jackffmm commented on GitHub (Jun 14, 2023):

In short:

Once QBT quits the user MUST be notified that its still running in background.
The files should be closed immedialtly (0.5s ?) once qbt recieve the term signial.

@jackffmm commented on GitHub (Jun 14, 2023): In short: - Once QBT quits the user MUST be notified that its still running in background. - The files should be closed immedialtly (0.5s ?) once qbt recieve the term signial.

deekerman commented

2026-02-22 01:19:27 -05:00

Author

Owner

@ghost commented on GitHub (Jun 15, 2023):

If AutoEndTask is enabled, windows automatically closes everything without waiting time. This means there isn't any notification.

@ghost commented on GitHub (Jun 15, 2023): If AutoEndTask is enabled, windows automatically closes everything without waiting time. This means there isn't any notification.

deekerman commented

2026-02-22 01:19:27 -05:00

Author

Owner

@jackffmm commented on GitHub (Aug 31, 2023):

To recap:
What you MUST do: add a banner that inform the user that the app is still open after the exiting (5 seconds).

What you SHOULD do: speed up the shut down, and quickly close all the files first.

I love this app, it just have this huge problem.

@jackffmm commented on GitHub (Aug 31, 2023): To recap: What you MUST do: add a banner that inform the user that the app is still open after the exiting (5 seconds). What you SHOULD do: speed up the shut down, and quickly close all the files first. I love this app, it just have this huge problem.

deekerman commented

2026-02-22 01:19:27 -05:00

Author

Owner

@drws commented on GitHub (Mar 24, 2024):

Closing of files should occur as early during shut down as possible. But depending on situation (fast downloads and/or slow storage) all the data might actually need some time to sync. Let's say the caches are filled, qBT needs to write 128MB of chunks and user has a SMR HDD sustaining some 15MB/s of write speed (since the caches are full). Hardware limits cannot be bent and in this example case 9-10-second shutdown time is to be expected. Just a single case to show that shutdown times in seconds are totally fine if there's a reason behind.

So there's only a problem with shutdown duration if it takes significantly more time than sensible, meaning qBT is doing something inefficiently or redundantly during shutdown. Although half a minute does seem high, there haven't been any concrete measurements yet to indicate such problems, so the problem with shutdown duration is yet to be confirmed.

What is definitely wrong is to exit the main thread or GUI, falsely notifying the system and user that the work has completed, and only then finish working with download data. That can definitely result in corrupted files and corrupted files might result in partially-corrupted filesystems. But deleting partitions is probably a description that is a bit off.

Regarding:

add a banner that inform the user that the app is still open after the exiting

Afaik qBT's GUI doesn't use make use of in-app banners and external solutions (including system notifications) are ugly to use in an ordinary workflow. The program simply shouldn't close until it is finished and display exit indication somewhere in the application. I'd even try to avoid a dialog window, which is admittedly a simple solution that works. If seconds-long exit times are a widespread occurrence also a progress bar showing the remaining data to be written during exit could be added (to the dialog window or somewhere in the GUI window) for the most versatile solution.

@drws commented on GitHub (Mar 24, 2024): Closing of files should occur as early during shut down as possible. But depending on situation (fast downloads and/or slow storage) all the data might actually need some time to sync. Let's say the caches are filled, qBT needs to write 128MB of chunks and user has a SMR HDD sustaining some 15MB/s of write speed (since the caches are full). Hardware limits cannot be bent and in this example case 9-10-second shutdown time is to be expected. Just a single case to show that shutdown times in seconds are totally fine if there's a reason behind. So there's only a problem with shutdown duration if it takes significantly more time than sensible, meaning qBT is doing something inefficiently or redundantly during shutdown. Although half a minute does seem high, there haven't been any concrete measurements yet to indicate such problems, so the problem with shutdown duration is yet to be confirmed. What is definitely wrong is to exit the main thread or GUI, falsely notifying the system and user that the work has completed, and only then finish working with download data. That can definitely result in corrupted files and corrupted files might result in partially-corrupted filesystems. But _deleting_ partitions is probably a description that is a bit off. Regarding: > add a banner that inform the user that the app is still open after the exiting Afaik qBT's GUI doesn't use make use of in-app banners and external solutions (including system notifications) are ugly to use in an ordinary workflow. The program simply shouldn't close until it is finished and display exit indication somewhere in the application. I'd even try to avoid a dialog window, which is admittedly a simple solution that works. If seconds-long exit times are a widespread occurrence also a progress bar showing the remaining data to be written during exit could be added (to the dialog window or somewhere in the GUI window) for the most versatile solution.