Qbittorrent: [Wishlist] portable version (Windows)

Created on 28 Feb 2013  ·  139Comments  ·  Source: qbittorrent/qBittorrent

Ideally, I'd like to simply have a .zip file with the qBittorrent files in it, ready to run.

Settings and everything would stay contained inside the qBittorrent folder, it wouldn't write outside of it or to the registry.

Feature request

Most helpful comment

integrate into the installer a portable option

That partially defeats the purpose IMHO. People who prefer their apps portable also generally prefer not to use installers (and use e.g. a zip package instead) - even if the installer would end up doing nothing more than copying the files into some dir.

However you look at it though, I think it always comes down to the executable looking for something at it's own exe directory - be it portable dir/config/whatever. So whichever approach is taken which does that, I think it would be OK.

All 139 comments

@Gelmir

What I suggest is much simpler. qBittorrent should enter "portable/standalone" mode when --portable is passed in the command or when qBittorrent detects the presence of a config folder in its directory when launched without the --portable option.

In portable mode it should save all its configuration files in a config folder which should exist in the same folder as the binary.

Furthermore, I don't know what is the norm in other portable apps but we should consider also changing the default save path from the current user's Download folder to a folder named Downloads which will be created in the same folder as the binary.

I'm personally against enabling portable mode automatically when config files are present in the folder. If you've used portable mode once, there's no going back unless you move files out of tree.

I agree on the --portable argument. But if we implement this we may as well implement profiles. Both will need modification of APPDATA and friends getters from settings class.

With profiling you will be able to switch between different configs by using command line --profile="whatever". This will append 'whatever' to config dirs of qBt, e.g. appdata/local/qBittorrent_whatever/ appdata/roaming/qBittorrent_whatever. Quite useful for debugging by the way :wink:

If you've used portable mode once, there's no going back unless you move files out of tree.

True but I wanted a way to automatically enter it, because user Joe will just double click the binary, he won't launch a terminal to pass it arguments. At least this is the case on Windows.

e.g. appdata/local/qBittorrent_whatever/ appdata/roaming/qBittorrent_whatever

I thought that portable apps should never save anything on the hosting machine. Just to their local folder, unless the user specifies otherwise eg Download the torrent in disk H:

I thought that portable apps should never save anything on the hosting machine. Just to their local folder, unless the user specifies otherwise eg Download the torrent in disk H:

That's for profiles support.

True but I wanted a way to automatically enter it, because user Joe will just double click the binary, he won't launch a terminal to pass it arguments. At least this is the case on Windows.

Hmm. I guess we could add a config option Do not enter portable mode automatically.

Too complex stuff the profile and the option. We don't need geeky features. We should focus on everyday use and make it simple but not too simple.

If we don't do a cmd switch+automatic detection, the other alternative is support it as a different build like we do with nox. In this case the user will always launch in portable mode regardless of cmd switch or automatic folder detection.

If we don't do a cmd switch+automatic detection, the other alternative is support it as a different build like we do with nox. In this case the user will always launch in portable mode regardless of cmd switch or automatic folder detection.

That would be really easy. But we need an early r+w check, if somebody places it into program files with UAC enabled under limited account. Should we also #ifdef the code to be windows-only? I don't see how portable version fits in Unix.


Btw. I was able to build nox under windows with some modifications (still requires QtGui for QDesktopServices). Speed was crap though, not sure why.

But we need an early r+w check, if somebody places it into program files with UAC enabled under limited account.

+1

Should we also #ifdef the code to be windows-only? I don't see how portable version fits in Unix.

No. It doesn't matter if it fits. nox doesn't fit on Windows but you can still compile it.

Btw. I was able to build nox under windows with some modifications (still requires QtGui for QDesktopServices). Speed was crap though, not sure why.

What does that work? Launch in terminal? Maybe the terminal is the bottleneck.

Too complex stuff the profile and the option. We don't need geeky features

Profiling has to possible application from my point of view:

  1. For Devs: quickly switch between daily use profile and debug profile
  2. For i2p users: switch between normal use profile and secure profile with anonymous mode.

What does that work? Launch in terminal? Maybe the terminal is the bottleneck.

Yeah. It starts in terminal.

I've dug through the code. fsutls class modification is required. That would be the easiest way.

I've dug through the code. fsutls class modification is required. That would be the easiest way.

Are you talking about nox?

Is there any progress on the (windows) portable version ?
In my opinion profiles would be overkill, the option to switch between profiles can also be achieved using 2 different portable versions... (you could still implement it at a later date anyway).
The easiest way I see it (on Windows), would be to detect qbittorrent.ini in the application folder.
So before people startup the app, they should create the file if they want the portable version.
Could that be a an option ?

Instead of profiles, I suggest an optional path to ".config" argument for the --portable switch, which would default to the directory with the executable.

Portable mode can be easily launched with .sh, .cmd, .bat or .lnk shortcuts.

I'm personally against enabling portable mode automatically when config files are present in the folder. If you've used portable mode once, there's no going back unless you move files out of tree.

Also, all the directories in settings and resume files should remember paths relative to the ".config" directory, unless they are on a different drive.
"Download/" - .config/Download/
"../Download/" - .config/../Download/
"/Download/" - [same drive]/Download/

Used portable mode successfully means:
You enables write permissions to the binary directory and passed executable a command like switch. Deleting .config directory should not be such a bit deal.
Or
You installed it on a portable-drive, in which case non-portable mode is not really applicable anyway.

It would also be ideal if windows profile were compatible with Linux so I could resume downloading/seeding after rebooting to Linux without sim-linking, renaming and forcing recheck.

My main objective is to keep an alternative profile and downloads on encrypted partition and be able reboot into Linux.

I tried using portableapps.com version, but it keeps saying it's already running.
I had to thinapp it, but it's crashing sometimes.

I do believe this has been resolved with the PortableApps version of the program. Their installers work perfectly well without the PortableApps platform and make applications wholly self-contained.

I do believe this has been resolved with the PortableApps version of the program. Their installers work perfectly well without the PortableApps platform and make applications wholly self-contained.

I don't think so. I haven't tested that version lately, but it still creates the qbittorrent.ini file inside your C:\Documents and Settings\<username>\Application Data\qBittorrent and C:\Documents and Settings\<username>\Local Settings\Application Data\qBittorrent folders

Guys, it's been two years. Can we finally get a portable version?

Guys, it's been two years. Can we finally get a portable version?
+11111

Can be realized as a program Multiminer https://github.com/nwoolls/MultiMiner - if the folder with program contain file "portable", then the program is portable :smile:

@MichielioZ commented on 2014. jan. 26. 16:45 CET:

Is there any progress on the (windows) portable version ?

In my opinion profiles would be overkill, the option to switch between profiles can also be achieved using 2 different portable versions... (you could still implement it at a later date anyway).

I agree.

The easiest way I see it (on Windows), would be to detect qbittorrent.ini in the application folder.

So before people startup the app, they should create the file if they want the portable version.

This seems like an unnecessary complication to me. The simplest is to just have a portable version. It may be an archive with a folder in it with all the files or a portable installer. And it would save all config/data/torrents in it's folder. (The default download path could be the system's download folder, because that's what's expected.)
No need to configure anything or create any files the portable version would be portable and stay that way.

would be to detect qbittorrent.ini in the application folder.

If only it were really that simple for a cross platform solution. :)

@Evropi commented on 2015. febr. 7. 18:41 CET:

I do believe this has been resolved with the PortableApps version of the program. Their installers work perfectly well without the PortableApps platform and make applications wholly self-contained.

It most certainly isn't. Flimsiest "portable" version I've ever seen from them.
Files are both created in appdata/local and appdata/roaming... And the added torrents are stored here.
I can't see, how can this even be said to be portable. One might say it's completely broken.
Also the default path I get is a butchered/garbled version of the path of qbt portable they intended. I can't handle characters with non-english diacritics, as we're still in the eighties....
And it's also an absolute path instead of a relative one, which is incredibly dumb for a portable app.

qbt-port

Well, it's a little different than I first thought. Apparently the data is copied from the portable folder when you run then is deleted on shutdown. Which might cause numerous issues, but at least it's sort of portable.

--portable, tried to launch but do not work, i hate portableapps version.

I hope the developer of qBittorrent is following this thread.
A portable version of qBittorrent would have many advantages but the most important for me would be the easier way to keep a back-up copy of qBittorrent. With portable uTorrent I regularly back-up its folder where it stores all its data and settings and maintaining these back-ups is extremely easy. While with qBittorrent I have to go to C:\Users\XXX\AppData\Local\qBittorrent first and copy it, then to C:\Users\XXX\AppData\Roaming\qBittorrent and copy it and when data corruption occurs (which happens very often with qBittorrent- in fact every time qBittorrent is not closed properly) I have to copy these copies back in AppData\Local and in AppData\Roaming. In several occasions I had to re-add hundreds of torrents manually. A natively portable version of qBittorrent would facilitate the process of backing-up of qBittorrent data and settings. uTorrent, Halite and Tixati have portable versions so I don't see a logical reason why qBittorrent shouldn't have an official portable version. I do not like PortableApps version of qBittorrent so I have to use the regular one, but saving its data and settings is unhandy and time-consuming. I am sure that a native portable version of qBittorrent would be appreciated very much by a great number of users and this is the feature which I miss most.

I doesn't seem like making qbittorrent portable is high on the priority list atm...
In the mean time, you could do what I have done: I pointed the folder on my AppData\Local & Roaming to my "portable" location. I know it's not really portable (maybe with a batch script to redirect them it could be, but not my usecase), but it works for the time being.

lets hope that after years there will be --portable command that works on every platform.

I registered just to echo the many people who are begging for a portable version.
This is pretty much the only reason I am not using qbittorent and sticking with utorrent 2.21 (which I don't want to)

The portable apps version is horrible. It spreads files all over system

The PortableApps.com package of qBittorrent Portable moves the files to/from the required locations for qBittorrent to use. qBittorrent requires that its files be within %LOCALAPPDATA%\qBittorrent and %APPDATA%\qBittorrent, so we (1) ensure a local copy of qBittorrent isn't running, (2) backup any data in those locations, (3) move the portable version's data to those locations, (4) adjust the paths in the confirguration, (5) run qBittorrent and wait for it to finish, (6) move the portable data back to the portable's Data folders, (7) restore the original backed-up data if there is any. Nothing is left behind unless Windows crashes or shut down without exiting the app. It's not elegant, but it's the only way to have qBittorrent run portably. If there were any command line options to point qBittorrent to its data files, we'd utilize them as we do in our other apps.

I was trying to email the original author of qbittorent. I am sorry I
emailed you in error I suppose. I appreciate your dedication to Portable
apps. I am a portable app fanatic, so I want to say: Thank you!

On Sun, Aug 2, 2015 at 9:47 PM, John T. Haller - [email protected] <
github.keepmy.d2f8a97cfc.notifications#[email protected]> wrote:

The PortableApps.com package of qBittorrent Portable moves the files
to/from the required locations for qBittorrent to use. qBittorrent requires
that its files be within %LOCALAPPDATA%\qBittorrent and
%APPDATA%\qBittorrent, so we (1) ensure a local copy of qBittorrent isn't
running, (2) backup any data in those locations, (3) move the portable
version's data to those locations, (4) adjust the paths in the
confirguration, (5) run qBittorrent and wait for it to finish, (6) move the
portable data back to the portable's Data folders, (7) restore the original
backed-up data if there is any. Nothing is left behind unless Windows
crashes or shut down without exiting the app. It's not elegant, but it's
the only way to have qBittorrent run portably. If there were any command
line options to point qBittorrent to its data files, we'd utilize them as
we do in our other apps.


Reply to this email directly or view it on GitHub
https://github.com/qbittorrent/qBittorrent/issues/465#issuecomment-127122865
.

@JohnTHaller
What I don't get is why can't you define %APPDATA% to be inside the portable folder for qbittorrent?

Hi John,
I consider myself an advanced user, and this could be incredible sleep
deprivation talking, but I don't understand how to do that. Hell, I don't
even know what that means. How do you 'define' %APPDATA% to be inside what
portable folder? I read your previous email.

Here is the situation: I am a new qbittorrent user. I don't mind starting
over with fresh settings. Portable apps qbit works by creating a 'wrapper'
so to speak and then moving those into the PA folder when qbit quits. I get
that part. The problem comes with updating the app. I can't just download a
RAR or ZIP file and extract it in that folder, nor can I use the
auto-update function as the app (qbittorent) asks me to do repeatedly.

Does that make any sense?

On Mon, Aug 3, 2015 at 12:26 AM, mzso - [email protected] <
github.keepmy.d2f8a97cfc.notifications#[email protected]> wrote:

@JohnTHaller https://github.com/JohnTHaller
What I don't get is why can't you define %APPDATA% to be inside the
portable folder for qbittorrent?


Reply to this email directly or view it on GitHub
https://github.com/qbittorrent/qBittorrent/issues/465#issuecomment-127147029
.

@stisev
My wording probably sucks. But it's an environment variable, right? Can't you overwrite an environment variable when calling a program?
In CMD you can definitely override the environment variables. (Just tried it.)

Does it require admin rights? It should be possible on even a guest account to be a true portable application.

We've found that redefining APPDATA, LOCALAPPDATA, or USERPROFILE can be unreliable and/or have unintended consequences on some Windows setups, so we stopped the practice quite some time ago. It's particularly troublesome where one app can be used to launch another... say, a torrent client running in 'portable' mode launching the default viewer for a a given movie and then having that local app storing its data within the portable app's folder. A redefined environment variable is passed on from process to process in Windows, so redefining any of the standard system variables can have unintended consequences. Even a clickable URL in the About window of an app can wind up with a local browser trying to use/create preferences within your portable app's custom APPDATA directory and then passing that on to any apps launched from that instance of the web browser. While an advanced user using their own portable instance of an app may have no issue keeping this chain of unintended consequences in mind and not launching one app from another, it's not something you could really expect an end user to always know.

:+1: I'm in favor of --portable parameter on startup. We just need to change the paths where config is stored.

Currently i use transmission on both platforms as portable, on linux(static) and on win. Transmission has command for this.

So people lets hope qBittorrent adds this soon.

@stisev Fosshub forwarded your email to me.

I am not against this. Whoever has time to implement it, I'll merge the patch after review. Currently no time from me.
As an experiment: I see a lot of vocal people here. Would anyone care to pay in BTC for this?

--portable parameter on startup.

how opening .torrent files with program would work then? - it won't

just check first if config n other files are present in the same folder first before going to %APPDATA%

i like Owyn idea too, like utorrent that check same folder. Should be cross platform.

like utorrent

I agree, uTorrent has a great solution for portability and so far everyboy liked it, and it's easy to implement it in this way.

Totally in agreement. I can't believe it took so many messages just to get
portability.
This is a real dealbreaker for me. I am forced to stick with Utorrent 2.2.1
until qbittorent gets native portability. Qbit is a great torrent client.
just needs portable mode :)

On Thu, Aug 6, 2015 at 4:24 PM, Owyn - [email protected] <
github.keepmy.d2f8a97cfc.notifications#[email protected]> wrote:

like utorrent

I agree, uTorrent has a great solution for portability and so far everyboy
liked it, and it's easy to implement it in this way.


Reply to this email directly or view it on GitHub
https://github.com/qbittorrent/qBittorrent/issues/465#issuecomment-128537825
.

I'm in favor of --portable parameter on startup. We just need to change the paths where config is stored.

I changed my mind because will be a mess deal with magnet links and file associations. I think is much better to have a compilation parameter. We can provide 2 different releases for Windows (standard & portable).

We can provide 2 different releases for Windows (standard & portable).

It's something.

But you'll have to compile and upload app twice everytime... why not just uTorrent way?

There are no complications. Like all single instance applications, qbittorrent extension handler starts, checks if another instance is already running and without even trying to read any configurations files just pass the files to that instance over IPC. There could even be one version installed and a version portable running. The installed one will handle the extension and pass it to already running one. That is already working, so any solution will work, even trough I'm in favor of the utorrent's one, which is btw how all the good/properly implemented portable applications work. Total Commander, Double Commander, Blender, eMule, Far Manager, AIMP, FindAndRun Robot, and many, many others.

I was going to try to implement that feature myself, but it was too complicated for me to compile qbittorrent on windows, especially configuring all the third-party libraries.

There are no complications. Like all single instance applications, qbittorrent extension handler starts, checks if another instance is already running...

and what if no instances are running (not even a single one) and user opens a .torrent file?

Then the installed one will start and load the default user profile. And if there is no installed one, then the extension/protocol was not registered in the first place, and nothing will happen.

I thought you was talking about --portable launch parameter, wasn't you?

Of course launch parameter. I don't see a reason to release a whole new version for a parameter that can be easily applied at run-time. And no one will compile it on windows by him/her-self.

However, I'm in favor of just checking for the presents of a config folder. It seems to be a matter of adding just a few lines of code in the main.cpp, replacing a few in fs.cpp and maybe a little debugging.
It's probably as easy as:
QDir dir("config");
if (dir.exists()) QSettings::setPath(QSettings::IniFormat, QSettings::UserScope, dir.absolutePath());
and use QSettings::fileName() to determine settings path in fs.cpp

And later to make it even better, make sure to save download location and other locations as relative paths if they are located on the same drive.

looks like final conclusion and best is cross platform config folder check, just like Blender.

I wish to see a portable version some day. Application should look for a configuration file in root folder first. If portable=1 exists then portable mode is activated. Just like Owyn said, if it can't find a config file in root, look in _AppData_ folder.

Any news? And My 2 cents.
Check data/config dir in this order:

  1. Environment variable %QBITTORRENT_DATA%. If set and dir doesn't exist or is empty then create a fresh qbittorent config. This is useful for launchers/shims.
  2. Flag in qbittorrent's app dir. This could be a directory with data or file with absolute/relative path to data/config dir.
  3. Using %APPDATA%

+1. just use ini files

Still no portable version? It's been almost 3 years. Do we need a kickstarter or something? C'mon please!

@bottleblue commented on 2015. dec. 30. 15:47 CET:

Still no portable version? It's been almost 3 years. Do we need a kickstarter or something? C'mon please!

Get a software dev friend to implement it and then make a pull request.

I'd rather just pay someone. Or keep using Tixati.

Tixati = no source, suspicious.

qbitTorrent = no portable, not handy.

qTorrent = no portable, not handy.

Do you mean qbittorrent ???

As qTorrent is a different species of bittorrent client that is NOT supported here.

I'd rather just pay someone. Or keep using Tixati.

Or use the portableapps version. It is not supported here or at the support forum (when it resurfaces), but it apparently works as one would expect.

I think this has already been mentioned but the portableapps versions is not truly portable as it writes to the %appdata% folder.

I think this has already been mentioned but the portableapps versions is not truly portable as it writes to the %appdata% folder.

You will have to take that up with them, but until one of the qbittorrent volunteer developers finds the fairly substantial amount of time it will take to fully convert the qbittorrent code ... for all operating systems, It's the best option available.

The PortableApps.com package is fully portable. It temporarily writes to APPDATA and LOCALAPPDATA while it is running due to that being the hard-coded path used by qBittorrent itself. As mentioned above, we: "(1) ensure a local copy of qBittorrent isn't running, (2) backup any data in those locations, (3) move the portable version's data to those locations, (4) adjust the paths in the confirguration, (5) run qBittorrent and wait for it to finish, (6) move the portable data back to the portable's Data folders, (7) restore the original backed-up data if there is any. Nothing is left behind unless Windows crashes or shut down without exiting the app. It's not elegant, but it's the only way to have qBittorrent run portably. If there were any command line options to point qBittorrent to its data files, we'd utilize them as we do in our other apps." Portable apps have always been allowed to temporarily write to the local machine: http://portableapps.com/about/what_is_a_portable_app

"Nothing is left behind unless Windows crashes or shut down without exiting the app."
If something can happen, it certainly will. And when it does happen, not only does it leave a whole mess behind, which defeats the whole purpose of it being portable, but it's not even starting afterwords, saying something like "the app is already running" with no way of telling where does it get this nonsense from. What also is left behind every time you run the PortableApps qbittorrent is the thousands of clusters on the hard drive containing the logs of what you have been downloading.

That is why I avoid using PortableApps as much as possible. I'd rather just add a portable switches to the shortcuts or use thinapp-like portabilizers.

It also looks like some of those apps are unnecessarily over portabilized and not in the right way.
uTorrent, for instance, does not need a portabilizer, especially as messy as this one. You just copy its executable in an empty folder with an empty settings.dat file and whoala, it's portable. If setting.dat is not there and it's not located in the program files folder, it offers to install itself.

Aimp comes with it's own portable installer. And many others also do.

Transmission-bt comes with profile switch and and its third party build runs great on windows with the smallest footprint of all the bittorrent clients. Yeap, that's what I'm using now, but I can't recommend it to an average person because to get the best out of it you need configuration files tweaking.

I think the author does not know how to do it, and is afraid to admit it. Some even offer to pay for it, so the conclusion arises by itself.

denisps - That's why all PortableApps.com apps make use of every single portablization ability available in the underlying apps and then expand upon it. The only reason qBittorrent is copied back and forth is because it's the only way to do it. uTorrent is only "kind of portable" with the settings.dat as it will leave a half dozen registry keys behind and some files in LOCALAPPDATA. Your torrents will also break as you move the drive from PC to PC as it uses full paths within settings.dat. The uTorrent Portable launcher handles all of that automatically. Transmission-Qt makes it so you can't eject your drive due to DBUS Daemon running and locking it after you exit. Our launcher handles that for users as well as portablizing paths.

Some users are fine with apps that aren't really portable (leaving files/registry keys, having settings or file paths break as you move PCs) as they're more concerned with not having to install them. Others want fully portable apps. We cater to the latter group.

Fossius - Someone saying they'll fund development vs actually putting up the funds to fully pay for a developer's time are two different things. Portable is a relatively small niche. And users who aren't satisfied with the existing portable option and want it done differently is a small niche of a small niche. You don't know what the developer's time commitments are like or what else is going on in their lives. Claiming they don't know how to do it is unfair and most likely inaccurate.

Some even offer to pay for it, so the conclusion arises by itself.

Let me hear offers in bitcoin. And then I'll start coding at 1st priority.

Let me hear offers in bitcoin. And then I'll start coding at 1st priority.

I don't have bitcoins but if Bountysource is enabled for this repository, I will contribute.

Bountysource allows people to put bounty on issues. If people want a feature, they can put bounty on it. Bounty goes to team/person who fixes that issue.

From Bountysource settings page:

This team is maintained by the community. This team has no members and the data below can be edited by any user. If you are a core member of this team please Claim This Team.

If enabled, Bountysource will also edit title when an issue gets a bounty (Issue title + bounty amount)

@JohnTHaller commented on 2016. jan. 5. 17:10 CET:

denisps - That's why all PortableApps.com apps make use of every single portablization ability available in the underlying apps and then expand upon it. The only reason qBittorrent is copied back and forth is because it's the only way to do it. uTorrent is only "kind of portable" with the settings.dat as it will leave a half dozen registry keys behind and some files in LOCALAPPDATA. Your torrents will also break as you move the drive from PC to PC as it uses full paths within settings.dat. The uTorrent Portable launcher handles all of that automatically. Transmission-Qt makes it so you can't eject your drive due to DBUS Daemon running and locking it after you exit. Our launcher handles that for users as well as portablizing paths.

Some users are fine with apps that aren't really portable (leaving files/registry keys, having settings or file paths break as you move PCs) as they're more concerned with not having to install them. Others want fully portable apps. We cater to the latter group.

Actually it can use relative paths. I have the save torrents path as ".\torrents" for ages.

Interesting that uTorrent finally fixed it and added relative path support back in. uTorrent used to support relative paths that mostly worked but then broke support for it in the original uTorrent 3.3 release. All the torrents in resume.dat would break every time you moved drives because they included full paths. We custom coded our launcher to be able to adjust them and work with the uTorrent fileguard setups within the files. At least that makes uTorrent more portable on its own if you disregard the registry entries and local files/folders it leaves behind on every PC.

@JohnTHaller commented on 2016. jan. 5. 22:39 CET:

Interesting that uTorrent finally fixed it and added relative path support back in. uTorrent used to support relative paths that mostly worked but then broke support for it in the original uTorrent 3.3 release. All the torrents in resume.dat would break every time you moved drives because they included full paths. We custom coded our launcher to be able to adjust them and work with the uTorrent fileguard setups within the files. At least that makes uTorrent more portable on its own if you disregard the registry entries and local files/folders it leaves behind on every PC.

I see. Well, I use 3.1.3, because later versions are advertisement filled garbage.
I'm also quite sure this version doesn't leave files behind. (Not sure about registry)

To implement this we add two options, avaliable via command line switches

so If I just open a .torrent file and program thus would launch without any custom command line switches I'd loose all my portable settings in this launch?

You may use environment variables for this case.

So environment variable has been added to set settings location if this issue is closed? what is command for that?

qBittorent command line parameters can be learned from its help output (qbittorrent -h). There you will find how to pass these parameters via environment variables.

What do all these recent replies have to do with portability? Does qbittorrent have a portable version now or commands to make it portable?

or commands to make it portable?

Yes, in the master branch.

Yes, in the master branch.

Are there instructions how to make it portable? I'm not sure if I can figure it out.

Have you checked its --help output?

I don't even know how to use the master branch :/

Then you have to wait for the next release.

ok thx.

Gongrats, very good and waiting for next release :) goodbye portableapps paf release.

Then you have to wait for the next release.

To be more precise you have to wait for the 3.4.0 release. It should the next one unless we discover bugs for the 3.3.x series, which will make me do a 3.3.13 release.

So let me get this straight:

  • You can use "--portable" switch to run portable mode. (based on the commit message)
  • Use an environmental variable. But how? Do you create an system or user environmental variable via Windows' system settings? But what's the variable's name and it's value?

Also, how on earth this second one be considered portable? You need to modify the system to set an environmental variable.

Here is a copy of qbittorrent --help from current master:

$ ./qbittorrent --help
Qt C locale unrecognized, using default (en).
C locale unrecognized, using default (en).
Usage:
        ./qbittorrent [options] [(<filename> | <url>)...]
Options:
        -v | --version          Displays program version and exit
        -h | --help             Displays this help message and exit
        --webui-port=<port>     Changes the Web UI port
        --no-splash             Disable splash screen
        --profile=<dir>         Store configuration files in <dir>
        --configuration=<name>  Store configuration files in directories qBittorrent_<name>
        --relative-fastresume   Hack into libtorrent fastresume files and make file paths relative to the profile directory
        --portable              Shortcut for --profile=<exe dir>/profile --relative-fastresume
        files or urls           Downloads the torrents passed by the user

Option values may be supplied via environment variables.
For option named 'parameter-name', environment variable name is 'QBT_PARAMETER_NAME' (in upper case, '-' replaced with '_')
To pass flag values, set the variable to '1' or 'TRUE'.
For example, to disable the splash screen: QBT_NO_SPLASH=1 ./qbittorrent

Command line parameters take precedence over environment variables

Use an environmental variable. But how? Do you create an system or user environmental variable via Windows' system settings? But what's the variable's name and it's value?

Yes, one may use Windows system settings, as well as his own launch script. BTW, doesn't Windows allow to specify environment variables in .shortcut file?

Also, how on earth this second one be considered portable? You need to modify the system to set an environmental variable.

That was an answer to question "How to open an URL or .torrent file using the portable mode?" And when one wants integration with system, there has to be a link between an app and the OS. For instance via an environment variable. What's wrong with that?

@evsh commented on Apr 12, 2017, 5:37 PM GMT+2:

Yes, one may use Windows system settings, as well as his own launch script. BTW, doesn't Windows allow to specify environment variables in .shortcut file?

I don't. I expect a .bat script is needed. Which is quite a nuisance. Does setting the variable help when you open a a torrent via double clicking an associated .torrent file, or do you get a different instance (or something worse)?

Is it possible that something more robust will be implemented? Most apps that support portable mode natively either check for configuration files in their exe's location, or a specific empty file (eg: "portable.dat").

Windows shortcuts allow to edit them to pass switches/arguments to the application.

IIRC, current portability implementation doesn't allow separate instances. If you have an already running instance with X profile any subsequent instance, no matter its profile, will pass arguments to the first one and then exit.

Does setting the variable help when you open a a torrent via double clicking an associated .torrent file

Can't understand you. You are OK with registry records for file associations, but don't want to set an environment variable? Besides, if qBt is running already (launched as portable), the second instance which is launched via a file association will just pass that file name to the running one and exit.

Is it possible that something more robust will be implemented? Most apps that support portable mode natively either check for configuration files in their exe's location, or a specific empty file (eg: "portable.dat").

Yes, certainly. For instance, we can look for $EXENAME.options file and read command line options from it if the file is readable. Would that satisfy your needs?

@evsh commented on Apr 12, 2017, 6:31 PM GMT+2:

Does setting the variable help when you open a a torrent via double clicking an associated .torrent file

Can't understand you. You are OK with registry records for file associations, but don't want to set an environment variable? Besides, if qBt is running already (launched as portable), the second instance which is launched via a file association will just pass that file name to the running one and exit.

My problem was reliability. Whether I can accidentally start QBT in non portable mode.
(Also it still might make sense to have QBT associated on my local machine for convenience's sake but still have it portable so I can move it to a different computer)

Yes, certainly. For instance, we can look for $EXENAME.options file and read command line options from it if the file is readable. Would that satisfy your needs?

That sounds great!

For instance, we can look for $EXENAME.options file and read command line options from it if the file is readable. Would that satisfy your needs?

That would be great

Looks like this didn't make it into 3.3.13?? :(

Nope, it'll be in 3.4.0

Did anything happen on this front?

@xbliss commented on 2017. jún. 29. 08:46 CEST:

Did anything happen on this front?

Try reading comments...

@evsh commented on 2017. ápr. 12. 18:31 CEST:

Yes, certainly. For instance, we can look for $EXENAME.options file and read command line options from it if the file is readable. Would that satisfy your needs?

Hello!
Did this happen? There was one commit after this one, but it doesn't detail what has changed. (As far as I can tell)
Update: I tried adding "--portable" to qbittorrent.options and qbittorrent.exe.options, so unless a different file is searched, it wasn't implemented so far.

@sledgehammer999 commented on 2017. ápr. 12. 18:29 CEST:

Windows shortcuts allow to edit them to pass switches/arguments to the application.

IIRC, current portability implementation doesn't allow separate instances. If you have an already running instance with X profile any subsequent instance, no matter its profile, will pass arguments to the first one and then exit.

Is this true to QBT installations in different locations also? If yes then QBT can't really be considered having a functioning portable mode. The host system might have a different instance running, which the user might not have rights to close. Apart from this a portable program shouldn't conflict with local or other portable instances at all.
Update:
So I tested this also, and sadly it conflicts with QBT instances from completely different folders.

a Portable installation in download section would also be nice btw when it's supported already (is it?)

@Owyn commented on 2018. febr. 6. 14:57 CET:

(is it?)

Not really. See above. You need pass an argument every time you start it. It also conflicts with other instances from other folders. eg: if you have a local QBT elswhere and a "portable" one.

@Owyn commented on 2018. febr. 6. 14:57 CET:

a Portable installation in download section would also be nice btw when it's supported already (is it?)

Oh yeah, forgot to add that that there's no distinct version. You just need to pass --portable to QBT v4.0+

As far as I understand, portable mode can be set via --portable CLI argument or some env vars, but not detected automatically via the presence of a portable config dir/file at the executable dir, is that correct?

If yes, can someone please explain the main objection to auto-portable by detecting via some ini file or dir at the executable dir?

The "pro" arguments for such auto detection were mentioned earlier, but to name a few: the common way by other apps is auto-detection, CLI args are not passed when invoked externally (via file association etc), and global env vars are both not easy to set for "normal" users, and some might consider them polluting, and more.

I didn't test this code nor ever compiled qBittorrent, but I did look at the code and it _seems_ to me that this patch (or something along those lines) could make it work in such auto-portable mode.

diff --git a/src/app/application.cpp b/src/app/application.cpp
index ebc32f909..e2ccf023c 100644
--- a/src/app/application.cpp
+++ b/src/app/application.cpp
@@ -118,9 +118,9 @@ Application::Application(const QString &id, int &argc, char **argv)
     setApplicationName("qBittorrent");
     validateCommandLineParameters();

-    QString profileDir = m_commandLineArgs.portableMode
-        ? QDir(QCoreApplication::applicationDirPath()).absoluteFilePath(DEFAULT_PORTABLE_MODE_PROFILE_DIR)
-        : m_commandLineArgs.profileDir;
+    QString profileDir = QDir(QCoreApplication::applicationDirPath()).absoluteFilePath(DEFAULT_PORTABLE_MODE_PROFILE_DIR);
+    if (!m_commandLineArgs.portableMode && !QDir(profileDir).exists())
+        profileDir = m_commandLineArgs.profileDir;

     Profile::initialize(profileDir, m_commandLineArgs.configurationName,
                         m_commandLineArgs.relativeFastresumePaths || m_commandLineArgs.portableMode);

Or maybe (handle relative paths better just below?):

diff --git a/src/app/application.cpp b/src/app/application.cpp
index ebc32f909..8e30efffe 100644
--- a/src/app/application.cpp
+++ b/src/app/application.cpp
@@ -118,6 +118,8 @@ Application::Application(const QString &id, int &argc, char **argv)
     setApplicationName("qBittorrent");
     validateCommandLineParameters();

+    if (QDir(QCoreApplication::applicationDirPath()).absoluteFilePath(DEFAULT_PORTABLE_MODE_PROFILE_DIR).exists())
+        m_commandLineArgs.portableMode = true;
     QString profileDir = m_commandLineArgs.portableMode
         ? QDir(QCoreApplication::applicationDirPath()).absoluteFilePath(DEFAULT_PORTABLE_MODE_PROFILE_DIR)
         : m_commandLineArgs.profileDir;

Would it work? would there be an objection to add it?

The author of this feature is inactive for months and i don't think the other devs follow this issue so let's call them @glassez @Chocobo1 ☝️

我感觉在目录下创建一个文件,如果exe检测到文件存在则自动便捷式岂不更好?

@1265578519 English please.

Hi!

This might not be the correct place to post, but after a few searches, I found that not many places talk about qBittorrent portable... So don,t hesitate to kick me out of this discussion if I am wrong posting here!

I want to test qBit portable and maybe eventually use it completely portable if it's as good as when installed...

A few questions before:

  • I found out that I can either download the pre-made Portableapps version, or make it portable myself by using the --portable switch. Are there any differences between the 2?

  • If I want to copy my settings and torrents from the normal version to the portable version, and vice versa, which files/folders do I have to copy?

  • I read a little above in this thread that the portable version used to copy stuff to APPDATA folders when starting and when closing it would copy back the data into the self-contained folder... Is it still like that? If yes, what's the purpose of running portable? Any crash would ruin all the purpose of being portable...

Thanks!

@j03bj03 便捷式版本文件结构,请参考压缩文件。
qBittorrent Stable (build 4.1.0.0).zip

@j03bj03 commented on 2018. aug. 14. 18:49 CEST:

Hi!

This might not be the correct place to post, but after a few searches, I found that not many places talk about qBittorrent portable... So don,t hesitate to kick me out of this discussion if I am wrong posting here!

I want to test qBit portable and maybe eventually use it completely portable if it's as good as when installed...

A few questions before:

  • I found out that I can either download the pre-made Portableapps version, or make it portable myself by using the --portable switch. Are there any differences between the 2?

I don't know what the portable app is now like, but the standard functionality is rather cumbersome. You always have to provide the --portable switch otherwise a local instance is opened.

  • If I want to copy my settings and torrents from the normal version to the portable version, and vice versa, which files/folders do I have to copy?

Everything in the profile folder

  • I read a little above in this thread that the portable version used to copy stuff to APPDATA folders when starting and when closing it would copy back the data into the self-contained folder... Is it still like that?

I guess you'll need to try it, and find out yourself.

I read a little above in this thread that the portable version used to copy stuff to APPDATA folders when starting and when closing it would copy back the data into the self-contained folder... Is it still like that? If yes, what's the purpose of running portable? Any crash would ruin all the purpose of being portable...

Unless I am hugely wrong, this doesn't happen with our portable mode. Only the with the PortableApps version. (which they might changed after we introduced the --portable switch).

I found out that I can either download the pre-made Portableapps version, or make it portable myself by using the --portable switch. Are there any differences between the 2?

I don't know if PortableApps changed their way after we introduced the --portable switch but until then they implemented their way of making an application portable.
Just grab our qbittorrent.exe from our installer and run it with portable switch. You might be able to open the extract the .exe from the installer by using 7zip and not actually installing qbittorrent.

@sledgehammer999 (or other devs), would you be able to comment on https://github.com/qbittorrent/qBittorrent/issues/465#issuecomment-367237178 ?

If environment variable is not enough, I would rather add reading comamnd line parameters from a named file rather than detecting profile directory. For example, adding qBittorrent.exe.parameters file with contents --portable to the executable directory would trigger the portable mode.

For example, adding qBittorrent.exe.parameters file with contents --portable to the executable directory

Sounds fine to me. Might not be super trivial to setup for newbies, but they'll manage, and looks to me like it would do the trick.

Looking forward to it ;)

I would like to suggest simpler and better methods (at least fir me) for triggering portable mode:

  • Portable flag in program folder - on program start qBittorrent checks program folder for portable flag, if it is there qBittorrent runs in portable mode;
  • Specific sub-folder in program folder - on program start qBittorrent checks program folder for specific sub-folder- for example data or qBittorrent, if it is there qBittorrent runs in portable mode;

I find these methods better because if the user forgets to start the program with the portable parameter (qbittorrent.exe --portable) data and settings would be saved to AppData.

I was happy to hear there was a portable mode but seeing it used CLI I gave up immediately. That's not simple or intuitive. Who wants to start up a program using CLI?
I agree use a portable flag or check for the data folders in the install directory or just offer a portable version. Other torrent programs have already done this (years ago). Why use a more complicated and annoying method.

@bottleblue 开发者技术不行,人品不好

@zeule commented on 2018. aug. 14. 21:56 CEST:

If environment variable is not enough, I would rather add reading comamnd line parameters from a named file rather than detecting profile directory. For example, adding file with contents --portable to the executable directory would trigger the portable mode.

I'm not sure using a generic parameters file for portable mode is such a good idea. I don't know who would use it but I think it's vulnerable to accidental manual, or programmatic deletion.

I think a separate, empty qBittorrent.exe.portable would be more robust.

Or have a separate compilation where the default mode is portable (requires some coding).
But people can still use either compilation with the appropriate flag to change modes.

@sledgehammer999 commented on 2018. aug. 15. 12:37 CEST:

Or have a separate compilation where the default mode is portable (requires some coding).

But people can still use either compilation with the appropriate flag to change modes.

Even better. One step further would be to integrate into the installer a portable option, so the users could generate any number of portable instances.

integrate into the installer a portable option

That partially defeats the purpose IMHO. People who prefer their apps portable also generally prefer not to use installers (and use e.g. a zip package instead) - even if the installer would end up doing nothing more than copying the files into some dir.

However you look at it though, I think it always comes down to the executable looking for something at it's own exe directory - be it portable dir/config/whatever. So whichever approach is taken which does that, I think it would be OK.

Old legendary uTorrent used settings.dat and qBt could use folder, if folder named config is detected then it will run as portable on Win and Linux. Blender uses similar idea if config folder is detected inside 0.00(enter version) folder.

@fcore117 https://github.com/qbittorrent/qBittorrent/issues/465#issuecomment-412940919 参考此楼,qbit目前的便捷版配置方式,快捷方式自行修改路径。

@avih commented on 2018. aug. 15. 14:45 CEST:

integrate into the installer a portable option

That partially defeats the purpose IMHO. People who prefer their apps portable also generally prefer not to use installers (and use e.g. a zip package instead) - even if the installer would end up doing nothing more than copying the files into some dir.

I fail to see how it defeats anything. You don't have to mess around with anything to get a portable instance. It's just more convenient. Escpecially if you don't have something to unpack the archive.

However you look at it though, I think it always comes down to the executable looking for something at it's own exe directory - be it portable dir/config/whatever. So whichever approach is taken which does that, I think it would be OK.

Well, the dev said otherwise. It could be compiled to be portable.

@sledgehammer999 commented on 2018. aug. 15. 12:37 CEST:

Or have a separate compilation where the default mode is portable (requires some coding).

But people can still use either compilation with the appropriate flag to change modes.

What point would it serve to be able to change modes when you have two separate portable/non-portable builds? It seems like a recipe for confusion to me.

1265578519: What are those square blocks you write i do not know? i see square blocks in row.

@1265578519 Why can't you speak English here?

@KozakaiAya 我键盘有问题打不出英语

@1265578519 Stop writing with chinese characters. Only the English language is allowed here. If you continue with Chinese I will delete your comments and/or report you.

Is there a portable version available for the current version? I see 4.1.0.0.zip posted above.

@unknownsoldierx commented on 2018. aug. 24. 11:19 CEST:

Is there a portable version available for the current version? I see 4.1.0.0.zip posted above.

Read the topic more carefully, there's a parameter that you need to use, no separate portable version.

I have. I saw the zip and thought there might be a stricktly portable version.

How do I get a browser such as Firefox to open torrents using "qbittorrent.exe --portable"

@unknownsoldierx commented on 2018. aug. 24. 23:14 CEST:

I have. I saw the zip and thought there might be a stricktly portable version.

How do I get a browser such as Firefox to open torrents using "qbittorrent.exe --portable"

Good question. Probably with a fair amount of tinkering. (That's why most of us don't like that it works this way). You can try the portableapps version.

Hello!

Does using qBittorrent in portable mode with "--portable" slow down qBittorrent if I seed a lot of torrents or is it the exact same thing?

Thanks!

The developers may have a look how portable mode is implemented in Tixati- tixati_portable_mode.txt file in program folder (where is the executable- 'tixati_Windows32bit.exe' or 'tixati_Windows64bit.exe') triggers portable mode- no command line parameters, easy, handy and simple.

Why is this even an issue? Let's review what we need to accomplish: settings independent of %APPDATA%/qBittorent when needed.

We could just not worry about whether the startup location is the installed location or not, and only check for presence of \Config folder under %__APPDIR__% (that's percent underscore underscore APPDIR underscore underscore percent, location of started qBittorrent.exe) where alternative config data would be stored, everything that'd usually be under %APPDATA%/qBittorrent.

No command line switches, no registry entries, will work when called from any other program, and maybe will enable a user to run multiple qb instances on the same user account too - make it so.

uTorrent works well with command line switches but the point of being called from other programs is a good one. For utorrent a working solution for multiple instances is simple renaming of the copies, so you'd have portable\utorrent\utorrent.exe , portable\utorrent-funnytracker\utorrent-funnytracker.exe, portable\utorrent-sadtracker\utorrent-sadtracker.exe etc.
This makes it easy to seed a large amount of torrents without getting confused about which process is which. A new instance is just a copy paste, rename, change of ports and new firewall rules.

Until we get auto-detection or a config file for this, it is already really easy to configure, if you use only one qbt instance, no need to fiddle with a .bat file or shortcuts...

  • On Windows use Win+R or Run command from Start, then key in

  • REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v QBT_PORTABLE /d 1 /f

  • Reboot.

The above just sets the QBT_PORTABLE environment variable.
After rebooting, qbt will start in portable mode, even when started from another program or when opening a .torrent file.

Until we get auto-detection or a config file for this, it is already really easy to configure, if you use only one qbt instance, no need to fiddle with a .bat file or shortcuts...

  • On Windows use Win+R or Run command from Start, then key in
  • REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v QBT_PORTABLE /d 1 /f
  • Reboot.

The above just sets the QBT_PORTABLE environment variable.
After rebooting, qbt will start in portable mode, even when started from another program or when opening a .torrent file.

I set this variable in Windows, that breaks torrents files that aren't (at least) in qbittorrent's folder (even downloaded files vere treated as bad), something was wrang with path after set this variable. This leads to redownload of torrent again and again.

P. S. I didn't tried to reproduce this bug in 4.1.7 version.

In the change log for version 4.2.1 I read this:

  • FEATURE: Enable portable mode if "profile" directory exists (Tester798)

Does this mean that if the user creates an empty profile sub-folder in program folder qBittorrent will be running in portable mode?

Can someone confirm this?

Does this mean that if the user creates an empty profile sub-folder in program folder qBittorrent will be running in portable mode?

Yes. It would have been incredibly easy for you to test this without reviving this old and closed issue.

@sledgehammer999

Thanks for the confirmation. Currently qBittorrent (version 4.2.0) is running and sometimes it is hard to exit it cleanly (without killing the process manually).

I needed to be sure about triggering portable mode in version 4.2.1 so that I could import all my data right (seeding hundreds of torrents).

I will try this on next reboot.

In 4.2.1 path are still wrong when torrent is in the same Volume whith qBittorrent (Windows OS): https://github.com/qbittorrent/qBittorrent/issues/11373

I tried this version here https://github.com/qbittorrent/qBittorrent/issues/11558#issuecomment-562835653
with stock config and the flag --portable, and I DLed a torrent, then restart QB and the torrent is not listed as erroneous.

the file is Dled in
D:\Documents\qbittorrent_4.2.0_x64_libtorrent_1_2_2_gitf49d194186profileqBittorrentprofileqBittorrent\downloads\

The error appears when the torrent is in the same Volume as qBittorrent (the same behavior as much earlier).
Снимок экрана (712)

What is the proper way to upgrade a portable instance?
The installer doesn't offer installing/unpacking files for a portable instance. Should I just extract files manually from the installer with an archiver program?

Was this page helpful?
0 / 5 - 0 ratings