When attempting to update my Pidgin Portable install to 2.10.3 from 2.10.2, I attempt to install it over the old install (as I've done the last 10 or so times I've updated). However, when I select the install folder, C:\Program Files (x86)\PortableApps\PidginPortable\ and click install, I receive the error:
"The destination folder you selected is invalid. Please choose a valid folder. [C:\Program Files (x86)]"
It looks like the installer is having a problem with the path, as it isn't reporting the full path that I'm actually selecting. I've installed upgrades to this directory in exactly the same way at least 10 times in the past without issue. Did something break with the new packaging for 2.10.3?
Any help would be appreciated.
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
The Program Files directory causes issues on Windows Vista, Windows 7 and Windows 8 in conjunction with UAC restrictions. Even with UAC disabled or when running from Windows 2000/XP, the location causes issues with several portable apps which switch to 'local mode' when they detect they are run from %PROGRAMFILES%. So, Program Files has never been a supported location for using portable software.
Unfortunately, many users still installed their software there and then wrote in with problems or questions, many of which were either unsolvable without disabling UAC (which causes other serious security issues) or unsolvable at all in the case of certain apps that operate in local mode (storing settings in the registry or APPDATA) no matter what when installed to Program Files. To alleviate these issues, the PortableApps.com Installer now checks and refuses to install to Program Files with the error you see above. The next release of the PortableApps.com Launcher (which is the AppNamePortable.exe) will have a similar restriction.
The solution is to move your PortableApps directory out of Program Files and into the root directory of your C:\ drive. Incidentally, this will also allow installers to automatically find it as you run them directly.
(For other users that may have installed to C:\Program Files\AppNamePortable, just create a C:\PortableApps directory and move the AppNamePortable folder to it.)
Sometimes, the impossible can become possible, if you're awesome!
Ok, I can see that. Could we make the error message more informative and add this restriction into the FAQ/helpfile so that it doesn't appear to be a different error?
There will be. Unfortunately, there wasn't time to translate it into all the different languages, so we went with a string we already had. And I purposely set it to just show the %PROGRAMFILES% directory instead of a subdirectory to indicate that that is the invalid directory. I've added to the generic install directions for all apps that we'll be switching to shortly.
Sometimes, the impossible can become possible, if you're awesome!
When you say "Please choose a valid folder. [C:\Program Files]" > it seems like Program Files IS valid folder
:.:.: ZoNi :.:.:
I think this is bad idea.
Anyone should have right to "install" portable programs wherever they want. Maybe good idea can be some warning that "Program files" is not the best solution, but I don't see why I have to be forced where to install my programs.
Now I have one step more when installing: I have to install in some "friendly" folder, and then to move to my Program Files folder (since it is logical all programs to be in one folder). Otherwise, I should move many shortcuts to my portable programs
BTW, add Serbia to the list of countries when registering for new forum account
:.:.: ZoNi :.:.:
seems to me that if you wanted to install a program in the programs folder you would not want to install a portable one but rather a base app?
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss
Nope. I like portable programs, but I like ALL my programs (portable and regular) to be in the same folder.
:.:.: ZoNi :.:.:
is that the location may break the program....so it may no longer be portable read above https://portableapps.com/node/31820#comment-193047
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss
I understand that. That is why I made this suggestion:
"Maybe good idea can be some warning that "Program files" is not the best solution, but I don't see why I have to be forced where to install my programs."
So, imho, warning is ok; forcing is not ok.
:.:.: ZoNi :.:.:
Is you have been explained why and also what to do to prevent it. Only other option is to not use Portable Apps version and then you are free to do as you please as no one is forcing you to use the protable version
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss
That is not the only other option
As I already told, I will "install" portable program to "friendly" folder and than move it to "Program Files" folder. One more boring step, but that is not that bad
[Gratuitous self-promotion link removed - mod Chris]
:.:.: ZoNi :.:.:
bas or Portable it is still licensed the same So your post and self promotion about your sight plays no impact on this conversation.
It is similar to this analogy. I live in an area that has a posted driving speed of 55 mph, a state near me has sped of 65 mph. Since my car is capable of traveling that fast how come I can not travel that fast wherever and whenever I want.
A proper solution instead of speeding is either one obey my home state laws or 2 move to another state that has faster speed laws. If I go with your solution then it would be to drive at what ever speed I want and when I get caught ignore the ticket and as soon as the police are gone speed again
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss
It isn't just a bad idea. It is completely unsupported. Always has been. Yet some people will continue to use it and file bug reports, no matter how many times we say it is a horrible idea and will break some apps and we don't support it/never have. So the installer won't let you install there. And the next release of the PortableApps.com Launcher (AppNamePortable.exe) won't let you run from there. We would have excluded it from the very beginning in the PA.c Installer, but we didn't think of a scenario where people would install it to Program Files at the time. Nor did we know many apps would break when installed there as we never tested or supported it.
If we still let people install there, we will still get duplicate bug reports about how XX app doesn't work right and stores its data in the registry/APPDATA (even though that is what it is designed to do when run from Program Files). And when users upgrade from XP to Vista or Win7 or Win8, they'll blame us when ALL of their portable apps stop working due to UAC (which we would never suggest turning off).
Sometimes, the impossible can become possible, if you're awesome!
For other users that may have installed to C:\Program Files\AppNamePortable, just create a C:\PortableApps directory and move the AppNamePortable folder to it. --- John, this will break all shortcuts and all program associations
This should be clearly stated, for not-so-experienced users!
:.:.: ZoNi :.:.:
You can use 8.3 filename:
C:\Program Files (x86) --> C:\Progra~2
That won't help as the apps themselves ensure they are not running from Program Files.
Program Files is not a valid location to run portable software from. On Windows Vista, Windows 7 and Windows 8, UAC prevents the apps from working properly, moving files, or saving settings. Even if you disable UAC (which is a bad idea) or are running on Windows XP, several apps detect when they run from Program Files and switch into 'local app mode' and store in the registry and in APPDATA instead of being self-contained and portable. And even if we allowed in on Windows XP when the user is an administrator, when they upgrade to Windows Vista/7/8, all their portable apps would suddenly stop working properly.
The solution is simply to create a folder at C:\PortableApps and install your portable software there. You can even move all your existing portable apps you installed to C:\Program Files to the new location and they'll keep working. Everything will work. And the installers will automatically detect that location.
Sometimes, the impossible can become possible, if you're awesome!
I am using win 7 pro 64 bit.
I have 226 portable programs stored in 226 different folders under the main folder
"c:\PROGRAM FILES_PORTABLE". I am now getting the above error when trying to install a portable program even though the error message says "c:\program files" is an invalid folder. I don't want to have to recreate 226 shortcuts.! I'm hoping you can fix this.
It should restrict based on %PROGRAMFILES%\ but from what you say it would appear to block %PROGRAMFILES% as well. Unfortunately, that would match your choice of %PROGRAMFILES%_PORTABLE. I can fix it in an installer update, but it won't fix any currently released apps, of course.
Did you just notice that now? Every single app since April 9th (over 3 months) has been packaged with this version of the installer so I'm surprised you didn't catch it before. You could just move each app you are trying to update now to something like C:\PortableApps as you update it and alter its extension then. The app will continue to work as expected. Once the new installer is out, any other new apps or updates will work as you'd like.
Sometimes, the impossible can become possible, if you're awesome!
If the NSIS is taking $PROGRAMFILES32/64 directly from the environment variable %ProgramFiles% it will only be matching against drive:\Program Files, not drive:\Program Files\.
Not that I have looked into the platform source to see if there are further manipulations going on with the env vars, NSIS still confuses me a little.
I rewrote the detection in PA.c Installer 3.0.4 to allow %PROGRAMFILES%_Portable and similar paths. Note that this only affects future releases and my original suggestion of switching to C:\PortableApps is the best scenario for most current releases. All releases from now forward will install in the path you want, though.
Sometimes, the impossible can become possible, if you're awesome!
on windows xp german version: i noticed that now i could not install to any(!) local folder on the system drive (c:\) that contains the word component "programme", e.g. c:\programme2, c:\portable_programme and so on.
("programme" is the german folder name for "program files" on xp)
the same folder name with a component "programme" on other drives than system-drive runs well. and unlike "c:\programme", the english folder name "c:\program files" works fine
btw i don't understand the deeper sense of these restrictions, i always thought, p.a. won't hurt the local system at all - as it did all the years before, even in c:\programme. that is why i also locally installed many programs in their portable version, to keep the system clean and fast. and they did the job, even on servers! thank you, John, for your great work!
Only apps that were updated after I wrote the above comment (July 25th) will work with C:\programme2. Earlier than that, they will incorrectly think C:\programme2 is within C:\programme\. Pidgin has not been updated since July 6th. Until then, use C:\PortableApps\. Realistically, it's far better to use that location anyway as installers auto-detect it.
The reason is explained in this thread. Several apps detect when they are running in Program Files and switch to local mode. They become NOT portable when run from Program Files. This is by design for these specific apps and can not be changed. It breaks portability. Plus, even though you can use apps installed to ProgramFiles on Windows XP, as soon as you upgrade to Windows Vista, 7 or 8, they will all stop working due to UAC security settings which prevent apps in ProgramFiles from writing to their own folder (unless you manually go in and turn it off, which we recommend against). Additionally, if we didn't have these restrictions, users installing under Vista and up could install them to ProgramFiles as an admin, but then have them fail to run when just running directly unless UAC is disabled. So, it's far easier to just say, 'nope, Program Files is for LOCAL apps only' and leave it at that to avoid the messiness of having to explain why certain apps fail, try and help users recover from upgrading Windows and all their apps stop working, etc.
Sometimes, the impossible can become possible, if you're awesome!
Hi guys,
I can't believe the draconian measures you've taken to prevent people from installing portable apps wherever they wish. You won't even let them move them to a PF folder and run them from there. Incredible... It makes me wonder if you had control issues as kids. :?|
I like portable apps for the same reason everyone does:
• They don't really have to be "installed" (their setups just expand and organize them).
• They keep their settings in their own folders—so once you've configured them, you can copy them anywhere and they run identically.
In other words, it's about convenience and control.
That's exactly why I want to keep my portable apps in my PF folders: I'd like the convenience and control of being able to keep all of my apps in one standard place. (It's called "Program Files", BTW, not "Non-Portable Program Files".)
If I understand you correctly, you're worried that if someone runs a portable app from a Program Files folder, and they haven't turned off UAC, it creates a UAC registry entry associated with that app—so it's no longer strictly "portable", right?
But it is. If you copy or move it elsewhere, you don't have to copy that string along with it. And I doubt anyone has worried about losing that string's tiny bit of drive space since the days of 10-meg hard drives. (Yes, I had one, if you're wondering!)
So this doesn't really seem like a "portability" issue. It seems like a control issue—yours versus ours.
Oddly, you have no problem letting users creating shortcuts to portable apps, even though shortcuts are outside of the apps's folders and (gasp!) stored in the Registry. Be honest—were you tempted to forbid that too? I can see it now:
Okay, I'm having some fun with you. Really, though—by preventing people from installing apps wherever they wish, aren't you actually defeating the idea of portability, and just imposing a different kind of installation enforcement?
BTW, one of the first things I do after installing Windows is to turn off UAC, and nothing terrible has happened yet. I use my own User Protection system, BPCS (Basic Precautions and Common Sense).
1. Nearly all users leave UAC enabled.
2. Under all supported versions of Windows (except XP, but only for 29 more days) portable software will simply fail to work when installed in Program Files as UAC is a standard part of Windows.
3. Even if you turn off UAC (bad idea, security-wise), several apps will run in LOCAL MODE. That means they'll store settings in the Registry and APPDATA when you run them in Program Files. Even though you're running AppNamePortable.exe, they'll run just as if you explored to the interior folder and ran AppName.exe directly. This is part of the base apps themselves when they determine whether they should be portable or not (not a good decision, not one we made, but one we have no control over). Other apps simply break and won't work right. And, here's the thing, we have no idea which apps will and which apps won't as they aren't tested to be able to run portably in Program Files. We'd have to test them all. And then test every single new version of every app to see if that changes. Which is messy, complicated, time consuming... and, honestly, unnecessary.
The bottom line is that Program Files is designed for locally installed apps only, and NO data or files that the app should be altering as they are running. Windows is designed like that and enforces this via UAC. True, you can turn it off, but almost no one does (nor should they) and, a future version of Windows will likely make UAC so it can't be disabled.
Sometimes, the impossible can become possible, if you're awesome!
Also, if you absolutely HAVE to run your apps from within Program Files, there is an undocumented & unsupported way to do so, look through the source for the PortableApps.com Installer or PortableApps.com Launcher.
Note that we WILL NOT provide any support for apps that do work as expected when run in this manner.
Gord > Also, if you absolutely HAVE to run your apps from within Program Files, there is an undocumented & unsupported way to do so, look through the source for the PortableApps.com Installer or PortableApps.com Launcher...
Thanks—but it'd be a bit silly, wouldn't it, having to jump through such hoops to do something that was supposed to be simpler than usual?
Hey John,
JTH> Nearly all users leave UAC enabled.
Dude, anyone who needs UAC to protect their PCs from themselves should leave it on, and should have to dismiss a full-screen message every time they run anything.
But as HowToGeek.com put it in their "How to Disable UAC" article (which came out shortly after Vista's debut):
Wow, a security feature that's so overbearing it inspires people to jump to other platforms—not good. :?D
The alternative is to learn enough about computing to install, understand and maintain good security software, and practice common-sense computing (e.g. stay away from disreputable websites, use software only from trusted sources) and keep your system secure yourself. That's what I've done since Windows 3.1, and it's worked fine so far.
JTH> Under all supported versions of Windows (except XP, but only for 29 more days) portable software will simply fail to work when installed in Program Files as UAC is a standard part of Windows.
Unless, of course, you turn it off. Odd, then, isn't it, that this site's own "Safe Portable App-ing" page (https://portableapps.com/support/safe_portable_app-ing) doesn't mention how important it is? In fact, it doesn't mention UAC at all—but it does describe some of the common-sense practices that make it unnecessary.
That said, your other observations have convinced me that portable apps aren't what I thought they were. I thought they were simply self-contained, no-install versions—which would be great, but it's clearly more complicated than that. It looks like they're primarily for people who want to carry their apps around on flash drives and run them from there. I think I understand now... I'll just return to the regular versions of stuff then. Thanks!
Once again, you ignored the main reason we decided not to allow with a warning: the fact that several apps switch to local mode when located within Program Files. We don't rewrite apps. We can't rewrite freeware. But some apps detect if they're in Program Files and save their settings in the registry or local APPDATA. When they're outside Program Files, they write their settings to their own directory. That's just the way they're coded. They do that no matter what we do with our launcher and packaging.
Other apps simply break when run in Program Files without being 'installed', including big apps like Google Chrome. And apps could work in Program Files in one version and then fail in the next one. I'm unsure why you keep overlooking these rather large, rather important issues with using portable software in Program Files.
It's not just about UAC. If it was *just* about UAC, we'd have a big ole warning as you tried to select it about how it's not designed to work there and you'll either need to switch UAC off or run as admin. And that there are security implications.
Create a PortableApps directory on C and install to there. All your apps will work. The installers will even auto-detect the location so you won't have to browse to it every time. And then you'll be able to take make use of the advantages of portable apps by easily backing up the apps and data to an external drive, making a copy to bring with you when you want, syncing a full working version of your apps and data to a cloud drive, moving all your apps and data to a new drive when you upgrade Windows, etc.
Sometimes, the impossible can become possible, if you're awesome!