For a start, the actual binary (C:\bin\qBittorrentPortable\App\qBittorrent) keeps writing into
C:\Users\%USERNAME%\AppData\Roaming\qBittorrent\qBittorrent.ini
== qBittorrentPortable.exe is not managing environment (changing at least APPDATA, LOCALAPPDATA)
Only when exiting is qBittorrentPortable.exe trying to do something and what it does? Moves the actual qBittorrent.ini, to C:\bin\qBittorrentPortable\Data\settings\AppData_qBittorrent
No close the process (from UI, no fault play involved), run C:\bin\qBittorrentPortable\qBittorrentPortable.exe again.
What happens?
C:\Users\%USERNAME%\AppData\Roaming\qBittorrent\qBittorrent.ini is back to some 5-line default.
== actual binary was started without .ini at all - so it created new.
Close the process again. What happens? C:\bin\qBittorrentPortable\Data\settings\AppData_qBittorrent\qBittorrent.ini is now obliterated - has that "first time" 5-liner plus a few others.
C:\Users\%USERNAME%\AppData\Roaming\qBittorrent.BackupByqBittorrentPortable\qBittorrent.ini was never changed. Why make a mess (anything "portable" has no business making extra folder in C:\Users\%USERNAME%\AppData\) and then not even use it ?
It also leaves a mess in C:\Users\Admin\AppData\Local\qBittorrent.BackupByqBittorrentPortable
The way it is right now it would work better If "portable exe" was a mere .cmd - at least it wouldn't obliterate config file which costs a lot of time (to go through all option in UI and then double-check them) and it would be clear, visible in one place, what it does.
Safety gone to neverland ?
Do I need to remind that a torrent client is safety critical binary == zero traces - ever, under any circumstances.
If someone claims to have made a portable version that would also include a config file for forcing paths that are "root relative" for:
Downloads\FinishedTorrentExportDir=
Downloads\SavePath=
Downloads\TempPath=
Downloads\TorrentExportDir=
without giving them "fancy" names to obliterate them. And a flag to turn the process on/off. Take "Downloads\TempPathEnabled=true" from qBittorrent.ini as inspiration - always a flag, presence/absence of data is not enough when something is more complex, not to mention safety critical.
root-relative means non-trivial replacement process - "root drive" relative would be half of the process (there would have to be a special symbol to state "movable drive root" or path beginning with [\] to denote it). It would have to be able to handle things like: ..\..\T\To and \PD\T\To
and a config right at the root (where qBittorrentPortable.exe) is for these values, plus a small .txt spelling out what's what and also where is the actual config for the actual binary so that a guy can check files and save what he needs and not waste enormous tile chasing things, only to see that it's obliterated.
There is Win32 API to tell OS to expand paths and it handles relative paths (including [\] is you check (and change if you need to) he current drive) and env vars - you just have to make sure you expanded before hijacking common env vars, but on the other side you can add your own - they'll be gone when your process dies,
Transparency, not obscurity. That help.html might be OK for basic stuff but a plain .txt is needed with actual (and short) info and critical data at the root.
Oh and for a safety critical binary you can't even assume that "data locations" are on the same drive with your binary => you need two config values - AppRoot and DataRoot or SafeRoot (that PAL:LastPortableAppsBaseDir=C: is not "base dir" at all - it's a root drive, base dir in this case was C:\bin - one up from AppRoot - the place where portable app was "installed") Examples: AppRoot=E:\bin\qBittorrentPortable, SafeRoot=F:\PD - root-relative paths for safety critical things start from SafeRoot, if there's a concept of a data location that's not safety critical, that's what DataRoot is for.
For better safety you'd need one more thing - the parent process to keep "pinging" SafeRoot and if it's "missing" to kill child process with full force (so it doesn't prompt to save anything - induced crash) and then itself. That's the real "pull out USB drive" scenario - drive vanished, you don't know anything - single event has to crash everything. And a flag in config to disable that of course ![Smile]()
