crash on windows = settings loss

deekerman commented

2026-02-21 15:51:13 -05:00

Owner

Originally created by @maxstepanov on GitHub (Oct 27, 2014).

I've been waiting for qbittorent to fix this bug for ~2 years now.
Every time my comp crashes(power outage or something else) qbittorent resets all setting but speed limits. Seems like all the issues regarding this bug are closed with advice to upgrade to 3.1.8 then 3.1.9
Well, now i'm on 3.1.11 and it still not fixed. Had a power outage today and i'm looking at "Legal notice" again like i'm running qbittorent for the first time. Speed settings are fine though. the only thing i don't care about. I wish all the settings could be like speed settings.
This is getting ridiculous...

Originally created by @maxstepanov on GitHub (Oct 27, 2014). I've been waiting for qbittorent to fix this bug for ~2 years now. Every time my comp crashes(power outage or something else) qbittorent resets all setting but speed limits. Seems like all the issues regarding this bug are closed with advice to upgrade to 3.1.8 then 3.1.9 Well, now i'm on 3.1.11 and it still not fixed. Had a power outage today and i'm looking at "Legal notice" again like i'm running qbittorent for the first time. Speed settings are fine though. the only thing i don't care about. I wish all the settings could be like speed settings. This is getting ridiculous...

deekerman closed this issue

2026-02-21 15:51:16 -05:00

deekerman commented

2026-02-21 15:51:19 -05:00

Author

Owner

@sorokin commented on GitHub (Oct 27, 2014):

I also experienced this issue on Linux 64-bit.

The first problem is that there is a bug in QSettings (https://bugreports.qt-project.org/browse/QTBUG-21739) which is only fixed in Qt 5.4. It is not released yet. qbittorrent contains a mitigation for this bug, but as I can see this mitigation contains an error that can lead to loss of settings too.

The current code does:

fsutils::forceRemove(final_path);
QFile::rename(new_path, final_path);

qbittorrent should just atomically rename on top of existing file and not remove existing file first. There are other places where non-atomic file overwrite happens (saving .fastresume data and other .ini files). They should be updated too.

@sorokin commented on GitHub (Oct 27, 2014): I also experienced this issue on Linux 64-bit. The first problem is that there is a bug in QSettings (https://bugreports.qt-project.org/browse/QTBUG-21739) which is only fixed in Qt 5.4. It is not released yet. qbittorrent contains a mitigation for this bug, but as I can see this mitigation contains an error that can lead to loss of settings too. The current code does: ``` fsutils::forceRemove(final_path); QFile::rename(new_path, final_path); ``` qbittorrent should just atomically rename on top of existing file and not remove existing file first. There are other places where non-atomic file overwrite happens (saving .fastresume data and other .ini files). They should be updated too.

deekerman commented

2026-02-21 15:51:19 -05:00

Author

Owner

@pmzqla commented on GitHub (Oct 28, 2014):

It seems that if qBittorrent_new.ini is available when qBittorrent starts, that file is used instead of qBittorrent.ini, unless it's empty.
In my opinion we should never use qBittorrent_new.ini on start, but simply warn the user that the settings of the last session might be lost. We are not sure that if qBittorrent_new.ini is not empty, then it's valid. It could happen that only part of the settings are written.

I think it's better to play safe and use a valid file, even if outdated, rather than a possibly corrupted one.

@pmzqla commented on GitHub (Oct 28, 2014): It seems that if qBittorrent_new.ini is available when qBittorrent starts, that file is used instead of qBittorrent.ini, unless it's empty. In my opinion we should never use qBittorrent_new.ini on start, but simply warn the user that the settings of the last session might be lost. We are not sure that if qBittorrent_new.ini is not empty, then it's valid. It could happen that only part of the settings are written. I think it's better to play safe and use a valid file, even if outdated, rather than a possibly corrupted one.

deekerman commented

2026-02-21 15:51:19 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Oct 28, 2014):

At least with recent versions you will not lose torrent specific settings (ie their savepath).
If you don't use private trackers that limit the software used, go to our forum and download the latest v3.2.0alpha build. That series contain code that tries to be much more robust in case of crash.

@ others. Atomic overwrites aren't part of qt api unfortunately. Also maybe the startup selection of ini files could be reworked.

@sledgehammer999 commented on GitHub (Oct 28, 2014): At least with recent versions you will not lose torrent specific settings (ie their savepath). If you don't use private trackers that limit the software used, go to our forum and download the latest v3.2.0alpha build. That series contain code that tries to be much more robust in case of crash. @ others. Atomic overwrites aren't part of qt api unfortunately. Also maybe the startup selection of ini files could be reworked.

deekerman commented

2026-02-21 15:51:19 -05:00

Author

Owner

@glassez commented on GitHub (Oct 31, 2014):

The main problem when using the ini file is that it is a simple text file with serial access. That is, if we want to change any value in position n, then we have to rewrite the entire contents of the file, starting from this position (as a minimum). At the same time we can not rely on this operation is atomic.
Ini files are good in situations where they contain static configuration, which changes very seldom (mainly at primary program configuring by directly editing the user in a text editor).
For about six months I have used in my patch assemblies that make use of the settings in the native format (I use Windows, so in my case the settings stored in the registry). During this time I have never lost the program settings (I even did a hard reset specially imitating power failure). I think this is due to the fact that the registry - not serial storage. Furthermore, since it is important for the system object, it is more protected from failures.
I did not propose this patch because recent modifications in the settings made by @sledgehammer999, fixed the problem with their loss (at first glance). But, as it turned out, it was not. Besides, there are a couple of reasons why I still did not. Firstly, any mention of Windows registry causes a lot of negative reactions from many developers (including qBittorrent maintainers). Although, in my opinion, the registry has a lot of advantages, and many his faults are often just the way it is used. Secondly, the use of the settings in the native format (most likely) can solve the problem only on Windows since on Linux (as far as I know) it's still used ini format, and MacOS uses XML, which is also serial.
With that said, I can offer to store program settings to use any storage that provides a mechanism of atomic writes. The simplest thing that comes to my mind, is SQLite database.

@glassez commented on GitHub (Oct 31, 2014): The main problem when using the ini file is that it is a simple text file with serial access. That is, if we want to change any value in position n, then we have to rewrite the entire contents of the file, starting from this position (as a minimum). At the same time we can not rely on this operation is atomic. Ini files are good in situations where they contain static configuration, which changes very seldom (mainly at primary program configuring by directly editing the user in a text editor). For about six months I have used in my patch assemblies that make use of the settings in the native format (I use Windows, so in my case the settings stored in the registry). During this time I have never lost the program settings (I even did a hard reset specially imitating power failure). I think this is due to the fact that the registry - not serial storage. Furthermore, since it is important for the system object, it is more protected from failures. I did not propose this patch because recent modifications in the settings made by @sledgehammer999, fixed the problem with their loss (at first glance). But, as it turned out, it was not. Besides, there are a couple of reasons why I still did not. Firstly, any mention of Windows registry causes a lot of negative reactions from many developers (including qBittorrent maintainers). Although, in my opinion, the registry has a lot of advantages, and many his faults are often just the way it is used. Secondly, the use of the settings in the native format (most likely) can solve the problem only on Windows since on Linux (as far as I know) it's still used ini format, and MacOS uses XML, which is also serial. With that said, I can offer to store program settings to use any storage that provides a mechanism of atomic writes. The simplest thing that comes to my mind, is SQLite database.

deekerman commented

2026-02-21 15:51:20 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Oct 31, 2014):

fixed the problem with their loss (at first glance). But, as it turned out, it was not.

Keep in mind that more serious code for fixing this is only found in git master(aka v3.2.0).

Furthermore settings should be editable by the user easily(eg using text editor).
It also seems that qt5.4 introduces a way to atomically rename/move a file. So it may be a good idea to switch officially to that. (maybe not for v3.2.0, since it also supports qt4.8 and I know what is the support of qt5.4 for the distros)

@sledgehammer999 commented on GitHub (Oct 31, 2014): > fixed the problem with their loss (at first glance). But, as it turned out, it was not. Keep in mind that more serious code for fixing this is only found in git master(aka v3.2.0). Furthermore settings should be editable by the user easily(eg using text editor). It also seems that qt5.4 introduces a way to atomically rename/move a file. So it may be a good idea to switch officially to that. (maybe not for v3.2.0, since it also supports qt4.8 and I know what is the support of qt5.4 for the distros)

deekerman commented

2026-02-21 15:51:20 -05:00

Author

Owner

@glassez commented on GitHub (Oct 31, 2014):

Keep in mind that more serious code for fixing this is only found in git master(aka v3.2.0).

Sorry, I have not thought about it.

So it may be a good idea to switch officially to that.

It's very good 😊

Furthermore settings should be editable by the user easily(eg using text editor).

This is really so necessary?

@glassez commented on GitHub (Oct 31, 2014): > Keep in mind that more serious code for fixing this is only found in git master(aka v3.2.0). Sorry, I have not thought about it. > So it may be a good idea to switch officially to that. It's very good 😊 > Furthermore settings should be editable by the user easily(eg using text editor). This is really so necessary?

deekerman commented

2026-02-21 15:51:20 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Oct 31, 2014):

This is really so necessary?

Yes. A text file helps in debugging. Also there are cases like this one: https://github.com/qbittorrent/qBittorrent/wiki/I-forgot-my-UI-lock-password

@sledgehammer999 commented on GitHub (Oct 31, 2014): > This is really so necessary? Yes. A text file helps in debugging. Also there are cases like this one: https://github.com/qbittorrent/qBittorrent/wiki/I-forgot-my-UI-lock-password

deekerman commented

2026-02-21 15:51:20 -05:00

Author

Owner

@glassez commented on GitHub (Oct 31, 2014):

Yes. A text file helps in debugging.

Debugging is problem of developers. Is it even necessary for ordinary users?

Also there are cases like this one...

This is one of those that don't change often. For them the ideal text format. They all tend to be located in the Preferences section. And only they, by and large, reflect the "program settings". Everything else can be called a "saved state". Store them in a single file, in my opinion, it is not logical (even if not to mention the file format).
But what is most amazing file qBittorrent-resume.ini - text file to store binary data?..

P.S. Please don't think that I impose my opinion. It's just criticism, which should only help to find the correct solution or to verify an existing one. If it really didn't need, then tell me and I won't do it. (Not only this issue, but in General).

P.P.S. Regarding https://github.com/qbittorrent/qBittorrent/wiki/I-forgot-my-UI-lock-password
I don't understand what is the meaning of this password. From what or whom he protects? If someone has access to your computer, they can also take advantage of the described method...

@glassez commented on GitHub (Oct 31, 2014): > Yes. A text file helps in debugging. Debugging is problem of developers. Is it even necessary for ordinary users? > Also there are cases like this one... This is one of those that don't change often. For them the ideal text format. They all tend to be located in the Preferences section. And only they, by and large, reflect the "program settings". Everything else can be called a "saved state". Store them in a single file, in my opinion, it is not logical (even if not to mention the file format). But what is most amazing file qBittorrent-resume.ini - text file to store binary data?.. P.S. Please don't think that I impose my opinion. It's just criticism, which should only help to find the correct solution or to verify an existing one. If it really didn't need, then tell me and I won't do it. (Not only this issue, but in General). P.P.S. Regarding [https://github.com/qbittorrent/qBittorrent/wiki/I-forgot-my-UI-lock-password](https://github.com/qbittorrent/qBittorrent/wiki/I-forgot-my-UI-lock-password) I don't understand what is the meaning of this password. From what or whom he protects? If someone has access to your computer, they can also take advantage of the described method...

deekerman commented

2026-02-21 15:51:20 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Nov 1, 2014):

Most of oss projects use text files for settings, anyway. Text files are easier to be shared.
I don't think this is such a big problem to actually discuss the format of the saving file.

Unless you want to propose the spliting of that file into too. One saving everything from the options windows. And the other saving column/header/window/whatever state.
This could be helpful and logical, but once we fix the main issue(which might already be fixed) it is moot.

But what is most amazing file qBittorrent-resume.ini - text file to store binary data?..

See #583. That issue also references a discussion I had with @sorokin for another commit.

@sledgehammer999 commented on GitHub (Nov 1, 2014): Most of oss projects use text files for settings, anyway. Text files are easier to be shared. I don't think this is such a big problem to actually discuss the format of the saving file. Unless you want to propose the spliting of that file into too. One saving everything from the options windows. And the other saving column/header/window/whatever state. This could be helpful and logical, but once we fix the main issue(which might already be fixed) it is moot. > But what is most amazing file qBittorrent-resume.ini - text file to store binary data?.. See #583. That issue also references a discussion I had with @sorokin for another commit.

deekerman commented

2026-02-21 15:51:20 -05:00

Author

Owner

@sorokin commented on GitHub (Nov 2, 2014):

A file format doesn't matter at all. With any file format you will get data loss if you do:

open+truncate existing file, write

Or:

create tmp file, write tmp file, remove existing file, rename

With any file format you will get atomic write if you do:

create tmp file, write tmp file, rename on top of existing file

@sorokin commented on GitHub (Nov 2, 2014): A file format doesn't matter at all. With any file format you will get data loss if you do: ``` open+truncate existing file, write ``` Or: ``` create tmp file, write tmp file, remove existing file, rename ``` With any file format you will get atomic write if you do: ``` create tmp file, write tmp file, rename on top of existing file ```

deekerman commented

2026-02-21 15:51:20 -05:00

Author

Owner

@yurikoles commented on GitHub (Oct 31, 2015):

Same on Linux. This is very old issue.

At least with recent versions you will not lose torrent specific settings (ie their savepath).
Yes, save past is not lost, but per-file settings is lost, also any directory or file renames.

@yurikoles commented on GitHub (Oct 31, 2015): Same on Linux. This is very old issue. > At least with recent versions you will not lose torrent specific settings (ie their savepath). > Yes, save past is not lost, but per-file settings is lost, also any directory or file renames.

deekerman commented

2026-02-21 15:51:20 -05:00

Author

Owner

@chrishirst commented on GitHub (Oct 31, 2015):

Same on Linux. This is very old issue.

and one that was fixed almost half a year ago!

@chrishirst commented on GitHub (Oct 31, 2015): > Same on Linux. This is very old issue. and one that was fixed almost half a year ago!

deekerman commented

2026-02-21 15:51:20 -05:00

Author

Owner

@yurikoles commented on GitHub (Oct 31, 2015):

Ok, maybe I use qBittorrent 3.2.4 from another Universe.

@yurikoles commented on GitHub (Oct 31, 2015): Ok, maybe I use qBittorrent 3.2.4 from another Universe.

deekerman commented

2026-02-21 15:51:20 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Oct 31, 2015):

@yurikoles if you do File->Exit does it still lose its settings?

@sledgehammer999 commented on GitHub (Oct 31, 2015): @yurikoles if you do `File->Exit` does it still lose its settings?

deekerman commented

2026-02-21 15:51:20 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Oct 31, 2015):

@yurikoles if you do File->Exit does it still lose its settings?

Forget that. You're talking about crashing...
Does it display the "legal notice" after every crash?

@sledgehammer999 commented on GitHub (Oct 31, 2015): > @yurikoles if you do File->Exit does it still lose its settings? Forget that. You're talking about crashing... Does it display the "legal notice" after every crash?

deekerman commented

2026-02-21 15:51:20 -05:00

Author

Owner

@yurikoles commented on GitHub (Oct 31, 2015):

No, I don't see legal notice. Also, I don't mean crash of the qB, it may be caused by system crash or reset of the system, that isn't relevant to qB. But I saw recheck of my files and reset of their state so many times.

@yurikoles commented on GitHub (Oct 31, 2015): No, I don't see legal notice. Also, I don't mean crash of the qB, it may be caused by system crash or reset of the system, that isn't relevant to qB. But I saw recheck of my files and reset of their state so many times.

deekerman commented

2026-02-21 15:51:20 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Oct 31, 2015):

You have a different bug then. This bug is about losing program settings. And I am closing it since I believe that it is fixed already.
Feel free to open a new one and include what the log says after the crash where it begins to recheck.

@sledgehammer999 commented on GitHub (Oct 31, 2015): You have a different bug then. This bug is about losing program settings. And I am closing it since I believe that it is fixed already. Feel free to open a new one and include what the log says after the crash where it begins to recheck.

deekerman referenced this issue

2026-02-21 19:48:46 -05:00

qBittorrent [still] doesn't respect selected download directory #8791

Rows
Columns

crash on windows = settings loss #1789