Hi all,
Is it possible/safe to move/transfer all portable apps between drives?
For example between two different USB memory sticks or from a USB portable hard disk drive to a USB memory stick?
Does it matter that the drives have different drive letters?
Many thanks.
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
Provided you only change drive letter and not path inside the drive, you will have no issues with our apps. They're all designed to cope with changing drive letters.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
???!! Do you mean that if I have, for example, the full suite of portableapps.com applications stored on my PC in D:\Utils\PortableApps then I can't subsequently copy then to a USB drive at M:\PortableApps? But that I have to re-install everything, and manually transfer all my settings and data?
That's a very, very long way from what I'd describe as "portable" - and certainly not how I understand the portableapps.com applications to work.
As a practical point, I'm pretty sure I've moved some apps (Firefox Portable comes to mind) like this in the past without problems.
I've always referred to the link on the left hand menu that says "What is a portable app?"
Here's the link again, just in case:
https://portableapps.com/about/what_is_a_portable_app
neutron1132 (at) usa (dot) com
Thanks for the link, I'd never spotted it before. To be honest, that's largely because I never particularly felt the need to check what "portable" meant, it's commonly (in my experience) used to mean an application which can be moved to a new directory without issue. (I could offer references, but it's no big deal - what portableapps.com means by "portable" is clearly stated in the link, even if it seems like a somewhat unusual use of the term to me).
And as has been stated, things do seem to work even if the letter of the law doesn't require it.
Personally, I would like to see it documented when an application isn't "movable" (I'm inventing a term here, as the term I'd expect to use is "portable" and that won't work :-)). Also, it would be nice to know how I should move an app if a simple copy won't work. It might be a bit of a slog to check everything, though
Just to explain my position, my interest is in having the PAc suite as a "copy and use" set of apps, which I can drop onto ant PC I need to use, but not to use on a USB device (as many of the environments I work in won't allow USB devices to be attached, but copy from DVD plus network sync is a viable alternative). In that sort of environment, directory names can easily change, and installing in the root is almost never an option.
But hey - I learned something, so that's good.
Paul.
You'll find that different people define the term "portable" in different ways, and each thinks they are correct. That's why that page exists.... it establishes what "portable" means here so visitors/users can understand what is being provided.
No offense, but when in Rome....
neutron1132 (at) usa (dot) com
Yes, while I have seen posts that state non-specifically that some apps might not work correctly if you move the Platform from X:\ to Y:\Subfolder\, I don't recall a verified instance of any specific Official PortableApp having that problem. If an app is incorrectly configured so that it relies on absolute paths, that could cause issues, but then they wouldn't be portable by any definition.
So I second that, and I'll phrase this in the form of a question to anyone who knows:
Which specific Official PortableApps will not work correctly if the entire platform and suite are moved from X:\ to Y:\Subfolder\ ?
I made this half-pony, half-monkey monster to please you.
Well, it's been mentioned here often that OpenOffice.org and LibreOffice have problems with long path names, I guess because they have quite a lot of levels of hierarchy in their folder trees. From personal experience I have also had problems with Google Chrome Portable when the name of the folder containing PortableApps was too long. Neither of these is directly connected to the moving of apps, but can still affect apps moved from X:\ to Y:\Subfolder if you put something substantially longer than the word "Subfolder" in its place.
No typin th las lette ca sav yo plent o spac
It should be noted that the issue with OO.o and LO is actually a limitation of the file system and operating itself where they exceed the max path length. It's nothing to do with portable software or something that can be fixed in code by us.
Sometimes, the impossible can become possible, if you're awesome!
"my interest is in having the PAc suite as a "copy and use" set of apps, which I can drop onto ant PC I need to use, but not to use on a USB device (as many of the environments I work in won't allow USB devices to be attached, but copy from DVD plus network sync is a viable alternative). In that sort of environment, directory names can easily change, and installing in the root is almost never an option."
That's very similar to my use case, and exactly how I've been using portable apps for some time. And it worked just fine for me, for the apps which I use, up until today. Ironically, the "app" which has stopped working "portably" (in the common sense usage of the term, not the PortableApps.com sense as mentioned in other replies) is the menu and launcher itself!
So with Portable Apps v2 I can copy and run the platform and apps from a root location of, say x:\apps, but with v3 I cannot (or at least I haven't yet figured out how to).
But, one change with v3 did cause a minor snafu.
The main executable for the PortableApps platform has historically been "StartPortableApps.exe" - but now it's just "Start.exe"
I'd had some shortcuts on my desktop, and in my startup folder, which failed after updating to v3.
I just had to change the target path in the shortcut to get it to work.
I made this half-pony, half-monkey monster to please you.
"Portable" to mean "can move from one computer to another" and such things. That doesn't generally involve changing path, just drive letter. Until recently with the PortableApps.com Launcher 2.1, we haven't paid any attention at all to the case of changing drive-internal path; as such, some (probably most) apps will work with it, some apps just won't update certain parts and so will be suboptimal while still approximately working, and some apps will break completely. For newer apps, though, we are paying attention to this, but it's still nowhere near most that actively support it.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
At first, Portable in the PortableApps.com definition means, it can be used on a portable drive on many different computers. Changing the drive letter is taken care of. As long as the folder structure stays intact, copiing the folders is possible - e.g. install in D:\PortableApps (the default setting) and copy the folder to any other drive resulting in X:\PortableApps.
Many apps can aditionally be copied to a different folder, but not all. If the base app is not folder dependent, no problem. There are some apps that are not originally portable and the launcher takes care of that, but for now can only function properly if the folder structure stays the same. The new PA.c launcher can handle the change of folders, but is only used by some apps for now, more to come.
-edit-
I'm too slow at posting, again...
The official line is that all platforms must be installed to the drive root, so they will always tell you that you need to keep the path exactly the same except for drive letter.
However, I can tell you that I have done what you are describing on many occasions and I have never had a problem.
Everything uses relative paths, but it doesn't care about anything above the level of the folder that has the StartPortableApps.exe file.
Try it and see - as they say, the proof of the pudding is in the tasting. So long as you use Copy instead of Move, you won't really risk anything.
I made this half-pony, half-monkey monster to please you.
It could be a lot of files to transfer, so it's better to Copy from one to the other. That way, if the process gets interrupted, you don't risk losing data; and then you can verify that the app work in the new location. After that, you can always remove the files from the original if you need to.
I made this half-pony, half-monkey monster to please you.
Most apps will work just fine when moved between directories. Many apps need no specific code to handle this. Some do and we provide that code to automatically handle directory moves (Example: All Mozilla-based apps like Firefox, Thunderbird, Sunbird, SeaMonkey, Instantbird and other apps like LibreOffice). Now that the functionality to do this is built into the base PortableApps.com Launcher itself, all apps are required to support this functionality and we're going back and double-checking if any old apps do not. The most you'll usually find is a few custom sound settings that break in apps that aren't fully compatible.
But, as pointed out above, portable always meant able to install to a removable drive and be moved between computers. This was the whole intent of portable apps back when I packaged the first portable app in Portable Firefox 0.7+, to be able to carry them around with you. Moving them between directories is more of a niche need for some users, but we support that as well now.
If you also move the Documents directory, though, many of those listed in most recent files lists will be broken, of course.
Sometimes, the impossible can become possible, if you're awesome!
I move portable apps from drive to drive often enough to use the term "all the time". In fact, if I set up portable apps for people, sometimes I'll just copy my folders over (deleting \data where appropriate, e.g. with Firefox). As others have stated, it's really only a problem with OpenOffice and LibreOffice.
A couple of years ago, I played around with this.
1. The USB drive on the computer I was using at a client site was locked down. They also locked down the registry preventing the installation of any apps that wrote to the registry, fortunately the PortableApps do not write to the registry. I copied everything to cloud storage from my hotel, then downloaded everything the c: harddrive, preserving the PortableApp directory structure. Everything worked flawlessly from the hard drive.
2. I copied everything from my 4 gb USB stick, primarily Portable Apps related, to a portable harddrive. Again, all worked well.
3. I upgraded to an 8gb USB stick. I copied from 4gb to 8 gb with no problems and all apps work perfectly.
Note: By selecting all (CTL-A), then a copy (CTL-C), then a paste (CTL-V) to the root of the drive; this preserved the PortableApp structure. Be prepared, it takes a while to move (copy/cut and paste) everything.
Bob
The time it takes to copy files is more than just the collective size, it also has to do with the number of files.
If you Select All and zip them (send to compressed (zipped) folder) then it reduces the size somewhat, but more importantly you are only moving one file - it should go a lot faster. Then once it's copied, just unzip it.
I made this half-pony, half-monkey monster to please you.
I don't really get the point of zipping and unzipping, because after you have copied the file to the other drive, by unzipping it you still write all the files to the (destination) drive. So you finish by writing all the files just the same as if you copied them and the big zip file.
Perhaps you gain some time because reading one drive and writing to the other doesn't happen at the same time, but you will certainly also need some time for zipping...
No typin th las lette ca sav yo plent o spac
Although the copy/paste instructions are correct, note that many PortableApps.com applications DO write to the registry, they just remove whatever was written when the application closes.
If they are correctly coded, any registry entries that matter are automatically removed when you close the apps.
So while you definitely should close all apps and the platform before copying/zipping, you should not have to poke around in the registry at all.
If there is any app that leaves registry settings* after the app has closed, then that's a bug and needs to be reported.
*Exceptions are known inconsequential registry entries like MRU. These entries have been discussed ad nauseum on this site, so a quick search should explain why they are not an issue.
I made this half-pony, half-monkey monster to please you.
Well, what happens if the registry is locked? Does the app ignore the registry write failure and continue, or does the app fail?
Of course, I'm in the "no portable app should ever touch the registry" camp, so that's my stance. Of course, I get admin access at work, so I'm not hindered (much) but I feel that's the best policy for those who aren't given such leniency.
not sure why or how this should be done , I mean the admin part ok, but the current users registry to be locked? Then you could not start most apps on windows anyway, this would be kind of strange system.
I dont know if it is in fact possible to make registry kind of read only, if it can be but then what for?
I have on all computers a restricted user only and have so far not met any instance with locked registry.
Otto Sykora
Basel, Switzerland
Basically with a "smart" registry lock the in memory image of the registry gets the edit but the on disk copy of the registry does not get the new data.
we have this on embeded windows, but this is then done in a way that the whole os variables are copied in a temp location and this is open and can be used during the run of the os, but is deleted on each shut down of the system and started with fresh copy each time. But this is special mechanism used in this embeded situation. But still, here all portable apps etc work normal.
But I can not so far see what advantages should a locked registry have. Or do you have some example as how I can imagine such system to operate? Where is it used and what for special reason?
Otto Sykora
Basel, Switzerland
I have just followed the advice of those above (thank you all) to move Portable Apps to my C: Drive for a awhile.
Fifefox works.
Thunderbird does not work.
Can anyone give me a suggestion on where to look?
TBird start screen comes up with the rotating circle for about 4 seconds... then just disappears.
Can anyone shed some light on this phenomena and a solution?
Lethal
and then check also your extensions, not all extensions are perfect and do not survive the move. But this is not fault of portable TB, it is fault of the particular extension.
Otto Sykora
Basel, Switzerland
EDIT: It was NOT the *copy* after all. It was the PATH LENGTH.
I copied from
e:\1234\LibreOffice\LibreOfficePortable_24.2.3_MultilingualStandard.paf\
to
c:\1234567890123456\12345678\LibreOffice\LibreOfficePortable_24.2.3_MultilingualStandard.paf\
And that made it crash.
I re-installed to that path on C:\ and it still crashed the same way.
Then I copied it from usb flash drive E:\ to a shorter path on C:\ and it worked.
--------------------------------------------------
I find portableapps extremely useful and very happy there is a portableapps LibreOffice.
So, just confirming: I installed LibreOffice to E:\path\LibreOffice (without the portableapps platform, just standalone).
Worked fine of course.
Copied to
C:\other_path\LibreOffice
Ie, changed the drive and the directory. Did not work.
Event log reported:
APPCRASH
CrashOnLaunch
Moved that to
C:\path\LibreOffice
Ie now only the drive is changed. And it DID work.
So confirming this problem is the same as it was 12-13 years ago.
I assume re-installing to my 'other_path' would fix it.
Last I checked, path changes on LibreOffice Portable are fine. You may have inadvertently made C:\other_path\LibreOffice too long, though. LibreOffice can't handle being installed to even a medium length path due to the huge nesting of files and folders within.
Sometimes, the impossible can become possible, if you're awesome!
You're right. I edited my post.