Hello.
PortableApps.com Launcher put RuntimeData in Data directory, and check it on startup to know if last exit is a good exit. In some case this may cause problems. For example:
- I run a portable app on computer A, the app store settings in registry and some data in AppData. I pull out the flash drive so the app didn't do a restore, and the RuntimeData file remain in data directory.
- Then I run the app on computer B, it found the runtimedata and do a restore. So my data and the local installed app on computer B are corrupted.
To avoid this kind of situation, when the app store it's major data in local computer when running, RuntimeData should be put in local computer, like $PROFILE.
Regards,
David
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
You should NEVER EVER pull a drive in use. It should be safely ejected. You can lose data within your apps and even physically damage the drive.
Storing it locally is not an option (goes against the portable mantra). The PortableApps.com Launcher 2.2 has a new way to maintain runtime data and will not be keeping track of whether it is running within the INI, eliminating this condition.
Sometimes, the impossible can become possible, if you're awesome!
I think the backup of existing local data isnt copied onto the drive but in a folder inside %APPDATA%. That still creates a problem of the data being not the right one if an launcher crashes and isnt run again on the PC.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Yes, this is exactly what I mean. New PortableApps.com launcher use mutex to know if the launcher is starting or stopping, but still use a runtime data to know if it crashed last time. In some case it's important to know if it's the right PC to copy data back.
We analysed this early on as we introduced crash recovery in 2.1 and decided that it didn't seem too big a risk (correctly or incorrectly we thought people would tend to be most likely to run on the same computer after such an event—I'm not so confident of my judgement in this matter now as I was then, though), and that it would be quite a bit of work to do it "properly". It may well be worth while revisiting this, though.
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
I wonder if perhaps such runtime data should be put in the registry (e.g. in
HKCU\Software\PortableApps\AppNamePortable)? After all this would be an easy way to have it stay where it's relevant, and then have something either random or based on something specific to the computer saved in the Data directory (and in the registry) to verify that it's restoring the correct data to the correct app?IDK, just a suggestion.~3D1T0R
If you write portable apps in basic nsis, it's easier to handel different runtime-datas base on the app's behavior:
If the app save it's data in %appdata% or registry, when crashed and run in another computer, there's nothing to restore, so put runtime data in local machine.
If the app simply store it's data in app directory and should be moved back after exit, put runtime data in Data directory.
If the app has both behaviors above, you can even make two runtime-datas, one in local machine and one in Data directory, check which one exists and decide which part of restore to do.
But it's more complex to do this in PAL, which is a universal launcher. I personal suggest create a option in launcher.ini like: [launch]:RuntimeData=Local/Portable. Let the developer to decide where to put the RuntimeData.
Best Regards,
David