I keep a folder named Misc Apps in my Program Files folder in which I place non-install/portable software I run from my hard drive. I tried running RBTray Portable from this location and got an error message:
"RBTray Portable (PortableApps.com Launcher)
---------------------------
RBTray Portable cannot be run from inside C:\Program Files. This location is for standard local software only. Please use this application from another location."
I find this annoyingly intrusive, and confusing. Would someone be kind enough to explain this to me? Why am I NOT ALLOWED to run the app from wherever I choose?
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Running from Program Files causes issues with UAC on Windows Vista/7, and on any Windows OS running from there causes some apps to run in local mode only, both of which can break portability and cause issues running the app.
Due to the large number of bug reports/complaints regarding portable apps breaking when installed to and run from Program Files because of this, PortableApps no longer supports running from Program Files, so it has been blocked in both the installer and launcher as a valid location to install to or run from.
Alright, but wouldn't it make more sense to pop up a warning rather than a totalitarian prohibition? At least allow a way to 'hack' it so a "power user' can do it anyway?
"My dear Mr Gyrth, I am never more serious than when I am joking."
~Albert Campion
But you need to be a power user to figure it out.
Previously known as kAlug.
If there really is a way would you be kind enough to point out what it is, or perhaps an information resource I could examine?
"My dear Mr Gyrth, I am never more serious than when I am joking."
~Albert Campion
Far too many people ignore warning messages yet still complain when things go wrong.
Considering the number of users who ask for a way to disable the clean-up warnings when running an app after it has been improperly closed (eg. shutting down Windows while the app is running) instead of changing their procedure to something that is safer for both their removable media and their data, I think it is quite valid to flat-out block installation/running of PortableApps from Program Files.
The workaround Aluisio speaks of is completely undocumented and unsupported, and as far as I can tell John wants it to stay that way. As a so-called "power user" myself, I wouldn't use it when the alternative (installing to a different location) is so much easier (not to mention tested, supported and working), and I don't recommend anyone else to use it either.
When a great many of your users are not 'that great' with computers and/or they are not very patient (read stupid/jerks) I can see why you would need to enforce a certain amount of control. I just tend to chafe against the idea of being told how I can or can't use a piece of software. This may not be reasonable, but it is still true.
Running your apps from an alternate path may be an annoyance, but it is a minor one at worst. Thank you for the explanation, and for your patience.
"My dear Mr Gyrth, I am never more serious than when I am joking."
~Albert Campion
An arbitrary and smug decision in my opinion, as well as sloppy implementation.
I don't use UAC and never had any issues at all with many portable apps stored in program files. A main purpose of this project is to liberate applications, so I strongly vote for giving back people the option to install/run where they want to.
At the very least check the path really is "program files" and not, for example, "program files (portable)" or "program filesthiswontwork" (as tested with a recent filezilla package).
As mentioned above, I already fixed the bug in the PA.c Installer that was locking out incorrect directories. It will take some time to make it to the apps that are affected, though. FileZilla hasn't had an update since then.
Also, as mentioned, several apps will continue to break in Program Files even if you have UAC disabled. We do not test apps for this condition. So, we'd just wind up with a stream of bug reports from people using them in Program Files and them not writing their data to the app's Data directory and having to tell them, again, that it's because they run from Program Files.
Sometimes, the impossible can become possible, if you're awesome!
Thanks John for the reply and path fix!
Your explanation makes sense from administrative viewpoint. While I'm not happy with the limitation I can live with putting portable apps in a custom path - it's more a matter of principle.
I think a disclaimer on install/launch with checkbox "Do not show again" would suffice.
We've tried warning people and explaining to them that Program Files breaks some apps and that we don't support it and never have. Yet, they still do it and complain again and again when it doesn't work right. And then get mad when they're told that it's the apps themselves that detect Program Files and that we don't support it. So, it's a no win. We made the decision to lock it out to prevent people from hurting themselves. Especially folks who use WinXP as admins and will break all their portable apps when they upgrade to Vista/7/8.
Sometimes, the impossible can become possible, if you're awesome!
One addition to what is mentioned above is when people upgrade Windows. Lots of folks are still running XP and were running portable apps of all types within the Program Files directory. What they didn't realize is that as soon as they upgrade to Vista, 7, 8, etc, all their portable apps will cease to function as they won't be able to write their settings files or move directories or files around within their own directories. The only workaround is to disable UAC, which isn't a good workaround.
Add that into the folks installing as an admin on Vista and up into Program Files and then confused why it doesn't work as a user, constant reports of X app doesn't work because it switches to 'local mode' whenever it is within the Program Files directory, and similar issues, and it makes far more sense to simply ensure folks are running from a proper location as opposed to a hacky and troublesome location.
Sometimes, the impossible can become possible, if you're awesome!