Option to save/restore all config settings.

[tempaccount102]

Occasionally Qbittorrent crashes and on restart reverts to its very original state with all config and customization settings reset. I had to manually reconfigure it about 10 times now and it's an infuriating process. All positions of window options, everything. Also, when that happens it deletes all torrents and I have to manually add them once again and recheck their contents. A nightmare. A recurring nightmare.
A simple backup system for settings would solve all this. And also would make migrating to a different computer very simple, just install a freshly downloaded Qbittorrent client and apply your settings file. Pretty pretty please guys! Thank you to everyone for your great work, this is truly an amazing piece of software!

[Chocobo1]

Before this (request) happens you can backup manually: https://github.com/qbittorrent/qBittorrent/wiki/Frequently-Asked-Questions#Where_does_qBittorrent_save_its_settings

[DRSDavidSoft]

I would also like a simple "Import/Export Settings" menu, so I could backup my view customization list, and migrate it to a new computer.

[Skytale]

For real guys..it's just dumping a json/xml file or w/e are you using in there...changed a lot of settings just 2 days ago - now everything lost again,. Like I don't have anything else to do that fix the configs..

[cyberfunk]

Vuze already has this feature and I was thinking about switching back to Vuze because of this. I will try the manual backup and see how smooth, streamlined that process is.

[dylanh724]

Man, this still isn't a feature? O_o competitors totally have this

[cyberfunk]

Manual backup works well for me:-)

[snifflezak]

Manual backup works, but it's not convenient to the end user. The code can't be that complicated either.

[j-quintas]

Yea, this would be a nice feature to have, windows these days with M$ pushing updates like crazy some formatting will happen, and it's a pain of configuring every program manually.

I vote for this.

[kingmustard]

I would prefer a proper option.

[MJCD]

Use the version from portableapps. Manually copy your backup over once, keep a clean copy of the entire (now customized) app for future (re)use.

Problem solvered.

[d-tork]

I run qBittorrent via docker-compose and even though I mount the /config and /data to a volume on my host drive, each time I have to rebuild it all the settings, categories, and torrents are lost. I'm not really sure how else I can handle backups, even "manually."

[mbd-shift]

also in favor of this!

I would also like a simple "Import/Export Settings" menu, so I could backup my view customization list, and migrate it to a new computer.

For real guys..it's just dumping a json/xml file or w/e are you using in there...changed a lot of settings just 2 days ago - now everything lost again,. Like I don't have anything else to do that fix the configs..

[stdedos]

Please add optionally also statistics (when https://github.com/qbittorrent/qBittorrent/issues/13386 is done, for migration purposes)

[Unix-Kernel]

Any status updates on this feature?

[Unix-Kernel]

Thanks, I will continue saving it manually until then +1:

[tsafs]

Any update on this?

[escape0707]

You can always replace the config path that qB will use by a symlink pointing to another file which will save the actual content.

Then, you can save all those actual files inside a folder and use git to sync them with other devices and GitHub, etc. I suggest collect $PROFILE coursera-dl.conf arai2.conf youtube-dl.conf bashrc vimrc zshrc mpv.conf..... etc, etc. All together.

Linux users have been using similar techniques to sync their shell, media player, software config for a long time. And it just works.

[tsafs]

Thank you, I have copied and pasted the config in %appdata%/qbittorrent

[MightyFlix]

You can always replace the config path that qB will use by a symlink pointing to another file which will save the actual content.

Then, you can save all those actual files inside a folder and use git to sync them with other devices and GitHub, etc. I suggest collect $PROFILE coursera-dl.conf arai2.conf youtube-dl.conf bashrc vimrc zshrc mpv.conf..... etc, etc. All together.

Linux users have been using similar techniques to sync their shell, media player, software config for a long time. And it just works.

That's the point; having to do this sucks. I want a simple and effective solution since the files are so prone to corruption; it's a major PITA to fiddle with the settings and manually add and recheck torrents, specially on hard drive storage. Other clients either have this by default or never crashed or corrupted config files with me. After using QB for less than a month it's already happened twice. I was happy to finally make the switch from Tixati to an open source client, but now I'm considering going back and this one simple, major thing hasn't been fixed ever since 2017.

[sakkamade]

Other clients either have this by default or never crashed or corrupted config files with me.

Ahaha. I wonder where did you read that qBittorrent does.
If you have crashes, open an appropriate issue.

After using QB for less than a month it's already happened twice

Have been using it over a year, have changed the platform in meanwhile, have never had corruption of config even once.

I was happy to change from ... Tixati to an open source client, &c., &c.

I presume you have wrong idea of the term "open source."

[sakkamade]

Any status updates on this feature?

Thanks, I will continue saving it manually until then +1:

@linuxlad Spare us your inchoate sarcasm.

[escape0707]

@MightyFlix

I want a simple and effective solution.

No.

I want to code a simple and effective solution.

Good.

[stdedos]

No you spare us your sarcasm.

Ahaha. I wonder where did you read that qBittorrent does. If you have crashes, open an appropriate issue.

Yes, we have. There's a reason there are 2.3k open issues (as of now), and most of them "closed due to inactivity".

After using QB for less than a month it's already happened twice

Have been using it over a year, have changed the platform in meanwhile, have never had corruption of config even once.

So that makes our reports of bugs "non-existent" because you haven't?

---

Thank you for your non-contributing comments; now pls go away.

[escape0707]

@stdedos

This project can have 2.3k valid issue, 2.3k qualified PR, but not 2.3k iS tHiS iSsUe FiXeD~ i WaNt iT sObAdLy!.

[sakkamade]

@stdedos Thank you for your honest boorishness; but if you have an examples where the crash of the client causing corruption of the config files, you would better mention them here to make this issue more relevant, and not simply display your mental nature.

And I wonder how much your commentary is contributing? (Your answer would be excessive.)

[MightyFlix]

Other clients either have this by default or never crashed or corrupted config files with me.

Ahaha. I wonder where did you read that qBittorrent does. If you have crashes, open an appropriate issue.

After using QB for less than a month it's already happened twice

Have been using it over a year, have changed the platform in meanwhile, have never had corruption of config even once.

I was happy to change from ... Tixati to an open source client, &c., &c.

I presume you have wrong idea of the term "open source."

I've edited my previous comment to be more clear, but the previous version was plain on this: I didn't read anywhere, just experienced it twice in less than a month; apparently you either couldn't grasp that or chose to ignore it.

Congrats for your anecdotal evidence, not what I'm looking for. This is the appropriate issue and it's open right now, others in this very thread already confirmed it happens, it would be a simple fix and it's kind of astonishing it hasn't been touched yet in 3 years. I was under the impression that open source can be improved by open discussion and that it could grow. Guess being condescending and giving people less reasons to use the software comes before helping fix simple QoL problems for users.

[MightyFlix]

@MightyFlix

I want a simple and effective solution.

No.

I want to code a simple and effective solution.

Good.

"I want" was obviously manner of speaking, I truly believe it would benefit all users to have a simple export config option and more robust torrent backup options. Do a Google search and check how many people had the same problem and see if it's not a relevant issue.

[sakkamade]

Now that's goes beyond any reason. And why do we must blindly believe your "anecdotal evidence?" I should think mine none the worse.

Thus I have advised you to open the issue (a separate one) in which you would describe how did it crash, how you are losing your config, and how this feature will be useful. I trust there was not such, presently, and it will be really helpful.

As for these words of mere abuse, try to throw them only after someone addresses them to you.

others in this very thread already confirmed it happens

Could you kindly point out these others? Save for that solitary three-year-old commentary of skytale, and another one with docker.

Edit:

you either couldn't grasp that or chose to ignore it.

The way you have putted your previous commentary clearly shows as though every second user experiencing this problem... As such you have probably read about it elsewhere.

[FranciscoPombal]

Yes, we have. There's a reason there are 2.3k open issues (as of now), and most of them "closed due to inactivity".

This is an unfair insinuation that either the issue tracker is mismanaged, or that the bugs are not getting fixed, or both. The issue tracker management has improved significantly since about 2 years ago or so - the singal-to-noise ratio is much higher, the vast majority of reports are assigned a label and receive a response from a project member or contributor within a short time of being posted, and the team members and contributors are able to more readily focus on the most pressing problems. Furthermore, contributors have been steadily fixing bugs and improving the project, even collaborating with upstreams such as libtorrent.

A lot of issues are closed because they suck (not enough information, can't be reproduced, the OP just dumped a non-reproducible report and bailed, users don't understand how BitTorrent works, etc.).

A lot of the time people either don't read the contributing guidelines or wiki and don't provide the information requested in the issue template, or don't have enough expertise to meaningfully contribute the required information to track down a legitimate problem, or their systems are utterly broken messes of anti-virus and bloatware that interferes with the normal operation of qBittorrent and other programs, or all of these or some combination of these at once.

Non-reproducible crash reports, or crash reports with no debug symbols of ancient versions are also not useful.

Also, a significant portion of the open issues are actually feature requests (almost 1k now: https://github.com/qbittorrent/qBittorrent/issues?q=is%3Aopen+is%3Aissue+label%3A%22Feature+request%22). Feature requests tend not be closed at all, as per the team's policy to increase the chances that someone will take it upon themselves to start a legitimate discussion and effort about implementing it. Then, it can either be rejected or accepted, and only at that point will the feature request issue be closed. Perhaps we should change this going forward; I've been entertaining the idea of moving all feature requests to the "Ideas" section under "Discussions"; the "Feature request" label would be reserved for issues opened about planning/discussion of implementation details of a feature request that someone wants to implement from the "Ideas".

Additionally, many of the opened reports right now that are not feature requests also suck and are on the chopping block next.

There's also a small portion of issues that are known but for which we must wait on something else in order to fix them (e.g. macOS ARM support).

---

Now for the issue at hand: I think there are other legitimate reports of qBittorrent failing to save/truncating configuration files/fastresumes under some circumstances that have so far not been addressed.

That being said, I don't think this feature is very useful. As mentioned in https://github.com/qbittorrent/qBittorrent/issues/6236#issuecomment-803307207, the UNIX way of backing up configs is the best way for most cases. Just backup the relevant config directories. No need to add a whole susbsystem in the GUI for that IMO, it's not like config files are scattered all over the place. In all platforms they're stored in well-known locations, with a well-known structure, and are even human readable!

EDIT: I should also mention that the "manual backup process" doesn't actually need to be manual. You can automate most/all of it. Check out the personal GitHub profiles of software/computer engineers/enthusiasts - some of them have (public) "dotfiles" repos that contain backups of all the important configs. They often have fully automated workflows in place to manage them. There are also many good write-ups online about automated config/dotfile management.

[stdedos]

This is an unfair insinuation that either the issue tracker is mismanaged, or that the bugs are not getting fixed, or both.

I am not trying to pick a fight with the project. Neither insinuate any of the aforementioned things; I am sorry if that somehow felt personal, one way or another.

I meant that you could be swamped, you don't have enough resources for everything, and you cannot cater to everyone's wishes/whims - apart from the fair points that you have also made.

I know that, if someone really wants something, they are free to try and do it themselves. I want to hope that I have not been extremely pressuring to the project, because I don't think there's a reason to resort to "I wanna!", "You are free to code it yourself!" type of discussion (which, makes sense, but IMHO it is a bit mean; if I could do it myself, I wouldn't have asked - I would've done it)

[FranciscoPombal]

@stdedos

I am not trying to pick a fight with the project. Neither insinuate any of the aforementioned things; I am sorry if that somehow felt personal, one way or another.

I meant that you could be swamped, you don't have enough resources for everything, and you cannot cater to everyone's wishes/whims - apart from the fair points that you have also made.

OK, fair, apologies for assuming the worst. The discussion was starting to derail so I erred on the side of caution and defensiveness.

I know that, if someone really wants something, they are free to try and do it themselves. I want to hope that I have not been extremely pressuring to the project, because I don't think there's a reason to resort to "I wanna!", "You are free to code it yourself!" type of discussion (which, makes sense, but IMHO it is a bit mean; if I could do it myself, I wouldn't have asked - I would've done it)

Honestly I don't think this particular feature request has a good chance of actually being implemented. I think the perceived need for this is both a self-inflicted problem (users who are not used to simply backing up their dotfiles/config files/folders) and a symptom of the fact that in some respects the format of the current config files leaves a bit to be desired. Concerning the latter point, IMO the main problem is that some key/value pairs are too opaque (e.g. stuff that gets stored as serialized QByteArrays).

I think "export" features are useful for user-defined presets of some specific functionality of the application or statistics, not the application's main configuration (think recording/streaming presets in OBS Studio). There is something analogous in qBittorrent already - for example, you can import/export RSS downloader configs.

Thus, I consider https://github.com/qbittorrent/qBittorrent/issues/13386 actually likely to be implemented at some point, and actually desirable, as opposed to this one.

[stdedos]

OK, fair, apologies for assuming the worst. The discussion was starting to derail so I erred on the side of caution and defensiveness.

Idk how it became all of a sudden that I am on the front seat of this; the feature request is quite older than my comment. All I did is reply to a toxic bully (quite politely, if I may say so). (If I start explaining my rationale, this will end-up being a small story)

I think the perceived need for this is both a self-inflicted problem (users who are not used to simply backing up their dotfiles/config files/folders) and a symptom of the fact that in some respects the format of the current config files leaves a bit to be desired.

It is my belief that this feature will make export/import easier: I don't want want to know how to back this up. If I press a button that says "Export/Backup configuration" then I know, whatever this is, it will give me a complete backup as a result, that's all there is to backup.

Likewise for restore - even a message that says "add your export.zip file in this directory (which can be auto-opened), exiting qbt now.", would make this more straightforward for the dummy user.

It's not that copy-pasting a directory is hard; it's the "hacky-ness" that this may feel to the Average Windows Joe.

Keep in mind that sometimes we have Windows users in the mix too ("backing up dotfiles" makes no sense to a Windows user).

---

My ultimate problem, and the real reason I am backing this feature up, is that there are occasions that qbt (or a subcomponent of, I won't claim to know), can end-up corrupting torrent data - which end up to lost statistics, torrents, fastresume etc.

If I really wanted to request a feature, it would be that qbt takes serious responsibility of its metadata: Backup (and verify) every exit/run, if qbt runs for hours continuously - backup every X hours. Failing to read the original metadata (e.g. because unsynced writes), then qbt backs them up (mv x x.corrupt) and tries to restore the backup. If it fails again then (idk what next).

If so, serious bugs like https://github.com/qbittorrent/qBittorrent/issues/6852 could be avoided (or mitigated).

I may be very precious with my data, and I don't like loosing them 😛

[sakkamade]

@FranciscoPombal

I think there are other legitimate reports of qBittorrent failing to save/truncating configuration files/fastresumes under some circumstances that have so far not been addressed.

Is this is a request for fastresumes also? Quote of OP:

Qbittorrent crashes and on restart reverts to its very original state with all config and customization settings reset.

I would have never considered fastresumes as a config files likewise. Please change the title to avoid any confusion if so.

That being said, I don't think this feature is very useful.

This is only your opinion. If many a people are actually experience the config loss, what some of users here rather desperately trying to imply, the user will decide whether this is useful or not.

I don't think this particular feature request has a good chance of actually being implemented.

Naturally, if even you do not mention any practical example.

@stdedos

All I did is reply to a toxic bully

This is me I presume, could you also point out what was there toxic, and where was that bully?

(quite politely, if I may say so).

You should re-read your commentary, you seem have forgotten what you have written...

Here is plain explanation of that commentary of mine:―

Other clients either have this by default or never crashed or corrupted config files with me.

Ahaha. I wonder where did you read that qBittorrent does. If you have crashes, open an appropriate issue.

Do not try to throw all the blame at the client, present a details of the issue you are experiencing: the problem may be from your (user's) side.

After using QB for less than a month it's already happened twice

This suggests the user is at fault even more, so:

Have been using it over a year, have changed the platform in meanwhile, have never had corruption of config even once.

I was happy to change from ... Tixati to an open source client, &c., &c.

What is here to be so happy about? A lot of proprietary programs with closed source code are amazing, so:

I presume you have wrong idea of the term "open source."

EDIT:

"You are free to code it yourself!" type of discussion (which, makes sense, but IMHO it is a bit mean

While escape0707 made merest jest, you have showed how gross you are. And for that commentary this ugliest discussion had commenced.

[MightyFlix]

@stdedos

All I did is reply to a toxic bully

This is me I presume, could you also point out what was there toxic, and where was that bully?

(quite politely, if I may say so).

You should re-read your commentary, you seem have forgotten what you have written...

Here is plain explanation of that commentary of mine:―

Other clients either have this by default or never crashed or corrupted config files with me.

Ahaha. I wonder where did you read that qBittorrent does. If you have crashes, open an appropriate issue.

Do not try to throw all the blame at the client, present a details of the issue you are experiencing: the problem may be from your (user's) side.

After using QB for less than a month it's already happened twice

This suggests the user is at fault even more, so:

Have been using it over a year, have changed the platform in meanwhile, have never had corruption of config even once.

I was happy to change from ... Tixati to an open source client, &c., &c.

What is here to be so happy about? A lot of proprietary programs with closed source code are amazing, so:

I presume you have wrong idea of the term "open source."

EDIT:

"You are free to code it yourself!" type of discussion (which, makes sense, but IMHO it is a bit mean

While escape0707 made merest jest, you have showed how gross you are. And for that commentary this ugliest discussion had commenced.

@sakkamade

You were toxic merely by not evaluating the usefulness of the feature for the people who asked for it, couldn't conceive for a moment that the feature was valid and asked me to code it, which obviously I can't or I wouldn't be adding my +1 to this issue.

You presumed whatever you wanted from my ramble (which I admit it was); I'm obviously happy to change to a codebase scrutinized by a community for such a privacy sensitive application, but Tixati has shown to be a more robust torrent database and file manager and if this keeps happening I'll have to revert to it, which is unfortunate since I would love to see this project as the better option speaking as a Windows user who doesn't normally fiddle with command-line scripting if it can be avoided.

It's so good that it's close to a perfect replacement for fully GUI-based alternatives for the Average Windows Joes out there, of which this issue presents one of the more serious shortcomings IMHO. I apologize if this maybe baited me into assuming that this kind of user-friendly feature would be in the interest of the project, since so many other things that point in that direction seen to be so well implemented. I know now that a full disk was to blame for the issue, but if the client had simple auto-backups of config files I wouldn't have lost all fast resumes, configs and stats, and it would have been a infinitely better experience for me and for others who complained about the same general scenario.

TLDR: Get down from that FOSS horse and try to actually evaluate and understand the issue and the people who asked for it before making negative comments.

[FranciscoPombal]

@MightyFlix

I know now that a full disk was to blame for the issue, but if the client had simple auto-backups of config files I wouldn't have lost all fast resumes, configs and stats, and it would have been a infinitely better experience for me and for others who complained about the same general scenario.

Don't take it personally, but the solution for backups is not for each program to implement their own backup solution, it's a dedicated tool and strategy for it. There are plenty of options to achieve this even on Windows with FOSS software and without touching the command-line, if you wish to be bound by those constraints. In the same veing, the correct solution to program updates is not each program implementing its own updater - it's software repositories/package managers. Windows is now slowly catching up to this (see chocolatey/winget/scoop and also ninite as an honorable mention for simple cases).

Unfortunately, Windows has incentivized users to do many things (software updates/backups/etc...) the "wrong" way for years. It's a mentality/habit/culture that will take a while to go away. Entire ecosystems have grown around it and further fed back into it (see for example the proprietary "driver updater"/"system optimizer" market).

Everyone here wants to make qBittorrent the best it can be. But sometimes that means rejecting certain features. For example, implementing an updater on Windows has been consistently rejected by the maintainer over the years for the reasons I outlined in the previous paragraphs - it's a Windows problem, not a qBittorrent problem. Even if a majority of other programs worked that way, that still wouldn't be a good reason for qBittorrent to do so as well.

[MightyFlix]

@MightyFlix

I know now that a full disk was to blame for the issue, but if the client had simple auto-backups of config files I wouldn't have lost all fast resumes, configs and stats, and it would have been a infinitely better experience for me and for others who complained about the same general scenario.

Don't take it personally, but the solution for backups is not for each program to implement their own backup solution, it's a dedicated tool and strategy for it. There are plenty of options to achieve this even on Windows with FOSS software and without touching the command-line, if you wish to be bound by those constraints. In the same veing, the correct solution to program updates is not each program implementing its own updater - it's software repositories/package managers. Windows is now slowly catching up to this (see chocolatey/winget/scoop and also ninite as an honorable mention for simple cases).

Unfortunately, Windows has incentivized users to do many things (software updates/backups/etc...) the "wrong" way for years. It's a mentality/habit/culture that will take a while to go away. Entire ecosystems have grown around it and further fed back into it (see for example the proprietary "driver updater"/"system optimizer" market).

Everyone here wants to make qBittorrent the best it can be. But sometimes that means rejecting certain features. For example, implementing an updater on Windows has been consistently rejected by the maintainer over the years for the reasons I outlined in the previous paragraphs - it's a Windows problem, not a qBittorrent problem. Even if a majority of other programs worked that way, that still wouldn't be a good reason for qBittorrent to do so as well.

I appreciate the frank response; but have you ever imagined that using a computer should be a simple, human readable experience, regardless of how Microsoft goes about it? I'm not here to change whatever preconceptions the project/its contributors have, or start a debate on any of the longstanding/sacred notions of what's the "wrong" or "right" way of doing things; but if that's what you believe, contributors/people active in this community should be prepared to explain it just like you did over and over again, because the truth is that if you have a native Windows client, that's the kind of questioning you'll get here, and just dismissing these users like what happened to me earlier in this thread won't really change anything or help anyone. Even if you do it politely like you did, my guess it that, in the end, a lot of people will feel something like the tone of the answer is "This project is not for Windows noobs" and they will look for something else, which IMHO could lessen the interest to contribute to the project (maybe it already has, who knows?) with very useful features like this one that would benefit so many users regardless of where they stand ideologically on how to code an UX.

[FranciscoPombal]

@MightyFlix

I appreciate the frank response; but have you ever imagined that using a computer should be a simple, human readable experience, regardless of how Microsoft goes about it?

IMO you can't divorce ease of use of computers from the attitudes of Microsoft in the past. My point is precisely that for a long time, the "Windows way" of doing things was counter-productive to the goal of increasing the ease of use of computers. It forced many people into sub-optimal patterns that they ultimately accepted as normal. Because of the way humans, habits, and inertia work, it is often quite hard and unpalatable to make the switch to other workflows, even if they are objectively superior (including in a sensible definition of a "ease of use" metric).

because the truth is that if you have a native Windows client, that's the kind of questioning you'll get here,

An interesting exercise: what is the spirit of such questioning? Is it along the lines of Every other/most/a majority of software on Windows does it this way/people on Windows are used to do things this way, why can't it be the same in qBittorrent??

Or perhaps more like Every other/most/a majority of software on Windows does it this way/people on Windows are used to do things this way, and I'm not familiar with any other way; can you explain what alternatives there are, and their advantages??

The former will always be met with opposition. If one wishes to convince me or others that each program having their specific updater/backup is the better solution, they have to come up with some good arguments. "Doing A because everyone else also does A" is not a good argument here (though it can be in some other contexts in the world of computing).

A similarly weak argument, which really translates to "it's difficult because I don't know it yet": "But it's not as easy to use" - against what exactly? What is the term of comparison here? rsync on the command-line isn't the only way to do backups. There are universal backup utilities that make doing backups extremely easy and user-friendly (not trying to throw shade at rsync here; in fact, I've seen many people adopt it enthusiastically after overcoming their command-line allergy). Do you prefer the nightmare of having to babysit each application's special-snowflake backup process and quirks to such tools? I find this false dichotomy to be quite prevalent - "I can either do this way that I've always done, or I can do it some other way that requires me to be a 1337 h4x0r with a CE/CS degree to implement and understand".

Even if you do it politely like you did, my guess it that, in the end, a lot of people will feel something like the tone of the answer is "This project is not for Windows noobs"

That is the wrong takeaway here. Me or others can always strive to better convey our message, but ultimately we can't stop all users from feeling that way. The onus is on the user to manage their preconceived notions about ease of use and alternative workflows. it's up to users to decide whether they are willing to reason about and experiment with different ways of doing things.

Consider the following: people who are used to Windows often cite the package manager-based flow for software installation as an obstacle to adopting Linux - too complicated/for nerds/whatever. Why not download installers from the Web like on Windows? Little do they know that the majority of people nowadays, including themselves, are most often using package managers and repositories to install software, and some on the younger side have never installed software by any other means on their computing devices. What on earth am I referring to? The Google Play Store and Apple App Store, of course. Do you think the mobile world would be better off the Windows way (though I agree they could certainly make it easier for users to install their custom/alternative "stores", but that's another problem...)? Do you think Google and Apple should do away with their repositories ("app stores"), because some people are not familiar with the concept, and rather than learn it, they try to get by with what they know and complain about what they don't as being unnecessary changes?

[MightyFlix]

My best example would probably be Foobar2k's foo_jesus plugin. With a simple GUI it configured automatic backups on every start-up/shutdown, allowing up to * (as many as you chose) different versions of backups of all configs/media database/other plugin's settings, deleted older backups over the chosen limit and allowed for the addition of more complex scripts to manage it if needed. A simple GUI based solution with command line extensibility available, which is probably one of the main reasons the whole foobar2k project was so successful back in the day.

I don't think it's a question of one method over the other at all, just giving different types of users options to have the power to do what they want.

[FranciscoPombal]

@MightyFlix

There's a key difference in that case that makes it an imperfect, but still fortuitous comparison for explaining some points: it's a plugin, not part of the main program or its development. The devs might even be against implementing it as core functionality in principle, and some users would consider it bloat/out-of-place in the program, but it sidesteps that entirely by being a community-contributed plugin. It's installation is optional, and the devs are not bothered by it or ideological debates about its inclusion.

Now, support for arbitrary plugins like that in qBittorrent is another story and feature request entirely... But if it were implemented, then this feature request could be satisfied by such a plugin.

[MightyFlix]

@FranciscoPombal The fact that it's a plugin is just a coincidence, it still ticks all the boxes of a good implementation of what you described; other examples of the same type of code as a native feature exist. Who would it be bloat for? Linux users? If Windows doesn't have proper backup support, waiting for it to be implemented 10 years from now will not address the problem anyway and serious Windows users would be happy by it's inclusion; hard to see how to be against that in the Windows client.

EDIT: Found out that BiglyBT has a very similar implementation to foo_jesus and that's where I'm moving next. I find your all your reasoning about software repositories lackluster, it's obviously not an apples to apples comparison of what we have in this instance. Still, that's exactly the kind of discussion I wanted to avoid, as it's outside the scope of this issue.

[stdedos]

The tl;dr problem is this: In this very specific case, having this implemented would in some way have mitigated https://github.com/qbittorrent/qBittorrent/issues/6852. And, while https://github.com/qbittorrent/qBittorrent/issues/6852 is an identified & confirmed bug, and it is claimed that sometime it will be solved, the truth is:

1. It is a confirmed bug
2. It is not solved after 4 years
3. I am afraid it won't be fixed anytime soon
4. It keeps on popping up

and, even if you claim that "this issue will not be a countermeasure"

5. There will be other bugs that will have to do with metadata corruption (that again this will shield from)

As for the "snowflake backup process": In turn, how do I know when are the fastresumes safe for backup by X tool? Are they synced at the time of copying? Are they written-through or do I need to sync manually? Does qbt respond to e.g. SIGUSR1 to do such operation? If it does, do I get some indication of success/finished/failed? 😕

I do agree that the way you are proposing around is "less special", but it does not make it "ordinary" - not at least when we are aware of file corruption issues, and we cannot scour the qbt source to verify and/or enforce some set of conditions.

[FranciscoPombal]

@MightyFlix

@FranciscoPombal The fact that it's a plugin is just a coincidence, it still ticks all the boxes of a good implementation of what you described; other examples of the same type of code as a native feature exist.

No, it makes all the difference, depending a project's goals. My point is that I would not oppose the implementation of such a feature on qBittorrent as plugin (if it were possible), but I do oppose it as a core feature.

Who would it be bloat for? Linux users?

This is not "us vs them" as in "Linux vs Windows users". It is bloat for anyone who subscribes to the idea that backup responsibilities should be delegated to... a backup program.

If Windows doesn't have proper backup support, waiting for it to be implemented 10 years from now will not address the problem anyway and serious Windows users would be happy by it's inclusion; hard to see how to be against that in the Windows client.

Where did you get the idea that there is no "proper backup support" on Windows? You don't have to wait 10 years, as I've said above there are countless ways of setting up nice backups on Windows, with the help of 3rd party tools (FOSS or not, GUI or CLI). If you mean "out-of-the-box" support, well, Linux doesn't have it either, you have to install programs and configure your preferred backup solution, unless you count including rsync in the default distro installation as "out-of-the-box support".

Even the users with the most rudimentary setups (cloud sync clients, that don't even qualify as proper backups) know that they have to install and configure their sync client of choice (e.g. OneDrive, Dropbox, MEGA, ...) - there is no such thing as pure "out-of-the-box".

Furthermore, what does "serious Windows users" mean? If it means "power users", then surely they are better served by, already know how to, or are willing to learn how to setup a proper backup strategy, with the appropriate tools for the job. On the other hand, if it means "users who are seriously invested in practicing bad habits promoted by Windows in the past", then I can't help those.

EDIT: Found out that BiglyBT has a very similar implementation to foo_jesus and that's where I'm moving next. I find your all your reasoning about software repositories lackluster, it's obviously not an apples to apples comparison of what we have in this instance. Still, that's exactly the kind of discussion I wanted to avoid, as it's outside the scope of this issue.

I'm glad you've found a client more inline with your preferences. As for my reasoning being lackluster, perhaps I haven't expressed myself too well, but if you look around you, you'll find that it is (fortunately) what the world is moving towards. All software on Linux is preferentially managed via the repo/package manager model (while having somewhat standard ways of "sideloading" software, like the convention of installing programs that are compiled from source to /usr/local). Same thing on mobile, but "sideloading" is much more restricted, unfortunately. Windows is also transitioning to it, via both 1st party efforts (MS Store, winget) and 3rd party ones (scoop, chocolatey, ninite, ...).

Much in the same way, slowly but surely people are adopting better backup strategies rather than relying on several different ones implemented by different programs whose purpose is not backing up files in the first place.

@stdedos

qBittorrent needs a proper solution to the truncation of files when there is no space left. The one proposed here would just be suboptimal stop-gap that would not solve anything. If qBittorrent truncates files to 0 while attempting to append to them/create them when there is no space left, what would happen to the backups? The exact same thing. Then we'd have even more bug reports complaining that qBittorrent corrupts its own backup files. If/when the truncation issue is fixed, such a config backup feature would become redundant anyway.

As for how other tools can deal with qBittorrent's files: the exact same way they deal with any other files, fastresumes are not special. Modern incremental backup solutions have no problem with it; they don't need the user to "stop the world" to backup files correctly. Not sure why you think you need specific guarantees about responses to SIGUSR1 or other stuff. The only thing you have to worry about in a correct backup setup is frequency and revision history length.

If you want a proper mitigation to the problem while the underlying issue is not solved, set up proper backups with standard tools for that purpose.

[stdedos]

If qBittorrent truncates files to 0 while attempting to append to them/create them when there is no space left, what would happen to the backups? The exact same thing.

My premise is:

1. You protect the current fastresumes
2. You write the new fastresumes
3. You verify their validity
4. If absolutely surely "OK", then you remove the backups (or, you don't - and you wait for the next round)

On high level, I don't see a problem with this logic. (I am of course wrong, but right now, it seems okay)

---

If you don't like that ... let's go with pre-allocated journaling 😛. I'd be glad to give +50 MB/~400 torrents away, if it meant that qbt gets higher assurances that it will be able to commit - or at least be able recover later / detect the error earlier. (but that's just MOAR complicated, isn't it?)

[FranciscoPombal]

My premise is:

1. You protect the current fastresumes

2. You write the new fastresumes

3. You verify their validity

4. If absolutely surely "OK", then you remove the backups (or, you don't - and you wait for the next round)

On high level, I don't see a problem with this logic. (I am of course wrong, but right now, it seems okay)

Yep, this is the solution to the underlying problem. If the core fastresume code worked like this, we wouldn't have this problem in the first place. This is the real fix, that's my point, which makes implementing this backup feature completely redundant.

[stdedos]

I guess then this should be tackled in libbittorrent? 😕

If so, it perplexes me that you have a confirmed bug open in your project and not at least tagged as "upstream / other project" (and/or closed as "invalid")

[FranciscoPombal]

@stdedos

I guess then this should be tackled in libbittorrent? confused

No, I don't think so. The wheels have been set in motion to migrate to a more robust solution: https://github.com/qbittorrent/qBittorrent/pull/14726. No ETA on when it might become the default though. But feedback about it is much appreciate it. You can download a test build from GitHub Actions that includes that change, if you want to test it out and provide feedback.

[stdedos]

@stdedos

I guess then this should be tackled in libbittorrent? confused

No, I don't think so. The wheels have been set in motion to migrate to a more robust solution: https://github.com/qbittorrent/qBittorrent/pull/14726. No ETA on when it might become the default though. But feedback about it is much appreciate it. You can download a test build from GitHub Actions that includes that change, if you want to test it out and provide feedback.

Well... Thanks, but no thanks 😕

The point is to have a stable platform (that I could sometime migrate to a NAS/Server). I don't feel like playing with 400GB of data and any potential disk churn / loss of (meta)data. I am so far not feeling that with qbt - let alone trying freshly-developed solutions.

[yamirui]

It doesn't help that this client seems to have at least 2 different config types, all in different formats for some reason... How hard can it be to add a button using qt and a dialog that lets you choose the export path? I personally use git to backup my whole home directory except data files that are mounted on separate drive and symlinked to from /home so its not an issue to me to backup... 5 qbittorrent config related files right now by simply adding and pushing to my home server once in a while but not everyone does that.

Mainly making this comment just so it doesn't get autoclosed due to inactivity (of maintainers), if I'm being honest.

[MightyFlix]

@FranciscoPombal

Yep, this is the solution to the underlying problem. If the core fastresume code worked like this, we wouldn't have this problem in the first place. This is the real fix, that's my point, which makes implementing this backup feature completely redundant.

If you can't fix that for the next 5 years it's not a real fix... The "bloatier" solution would obviously be adding a backup solution to my setup for the one single amateur software that doesn't include it (as is the case of many windows users I would bet) for "reasons".

[raffaem]

I need to switch from the Flathub version to the DNF one and I need this feature to port my torrents and settings