[Wishlist] portable version (Windows)

[jpff]

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.

[sledgehammer999]

@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.

[Gelmir]

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:

[sledgehammer999]

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:

[Gelmir]

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.

[sledgehammer999]

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.

[Gelmir]

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.

[sledgehammer999]

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.

[Gelmir]

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.

[Gelmir]

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

[sledgehammer999]

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

Are you talking about nox?

[MichielioZ]

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 ?

[denisps]

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.

[ghost]

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.

[sledgehammer999]

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

[aaaxx]

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

[Fossius]

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

[Fossius]

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:

[mzso]

@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.

[chrishirst]

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

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

[mzso]

@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.

[mzso]

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.

[fcore117]

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

[smaragdus]

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.

[MichielioZ]

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.

[fcore117]

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

[NikoMuffin]

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

[JohnTHaller]

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.

[NikoMuffin]

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 - notifications@github.com < github.keepmy.d2f8a97cfc.notifications#github.com@ob.0sg.net> 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 .

[mzso]

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

[NikoMuffin]

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 - notifications@github.com < github.keepmy.d2f8a97cfc.notifications#github.com@ob.0sg.net> 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 .

[mzso]

@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.)

[ghost]

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

[JohnTHaller]

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.

[ngosang]

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

[fcore117]

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.

[sledgehammer999]

@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?

[Owyn]

--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%

[fcore117]

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

[Owyn]

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.

[NikoMuffin]

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 - notifications@github.com < github.keepmy.d2f8a97cfc.notifications#github.com@ob.0sg.net> 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 .

[ngosang]

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).

[Owyn]

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?

[denisps]

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.

[Owyn]

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?

[denisps]

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.

[Owyn]

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

[denisps]

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.

[fcore117]

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

[dogancelik]

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.

[shoomyst]

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%