There are some apps, that don't use AppData folder to store their data, but rather CommonAppData folder (usually C:\ProgramData). Is there any way to make such app portable and "redirect" this folder using [DirectoriesMove]?
New: Kanri (Oct 9, '24), Platform 29.5.3 (Jun 27, '24)
1,100+ portable packages, 1.1 billion downloads
No Ads November!, Please donate today
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're looking for the ALLUSERSAPPDATA environment variable.
See here: https://portableapps.com/manuals/PortableApps.comLauncher/ref/envsub.htm...
Alternatively you could use
custom.nshNow you can use
%PROGRAMDATA%in[DirectoriesMove]as well..If you do not know what the above code I shared is doing then stick with the way Gord said to do it as it should work across all OS versions and what I did was just created a new environment variable to say ProgramData instead of saying AllUsersAppData.
daemon.devin
Just use
%AllUsersAppData%, its tested, documented, and already there. No need for aCustom.nshwhich would require rebuilding the launcher to include.~3D1T0R
Thank you very much for your kind replies!
Unfortunatelly, %ALLUSERSAPPDATA% variable is not working for me. The app is creating the proper folders in ProgramData folder on my local machine, but doesn't copy any data to this folder - it is just empty folders. The app relies heavily on the data in ProgramData folder and thus doesn't work.
I probably have some problem with my folder structure.
Let's assume that I have this code in my launcher:
[DirectoriesMove]
-=%ALLUSERSAPPDATA%\Data1a
-=%APPDATA%\Data2b
AppNameConfig=%ALLUSERSAPPDATA%\Data3c
Where should I place the Data1a, Data2b and Data3c folders with the data they contain within my DefaultData folder? Should I just copy them to Default data like this:
AppNamePortable\App\DefaultData\Data1a
AppNamePortable\App\DefaultData\Data2b
AppNamePortable\App\DefaultData\Data3c
Or should there be folder structure like
AppNamePortable\App\DefaultData\ALLUSERSAPPDATA\Data1a
AppNamePortable\App\DefaultData\APPDATA\Data2b
AppNamePortable\App\DefaultData\ALLUSERSAPPDATA\Data3c
Neither of this works for me.
Have tried to learn this from already compiled portable apps that can be downloaded form this site, but can't find no app that heavily uses APPDATA and ALLUSERSAPPDATA folders
You're looking for the first option, sort of.
Anything started with -= is discarded when the application is closed, so you don't need to have anything in the DefaultData folder for those lines.
The AppNameConfig config line will be moving anything stored in
\AppNameportable\Data\AppNameConfigto%ALLUSERSAPPDATA%\Data3c.As such, if you need anything to be in that folder by default, you need to include that data in
\DefaultData\AppNameConfig.Ah, now it makes sense! Thank you very much!
What if I need to copy multiple folders and their contents to both AppData and AllUsersAppData folders?
I need folder structure like this on my local machine:
ProgramData\Data1a\File1a.dat
AppData\Data2b\File2b.dat
ProgramData\Data3c\File3c.dat
ProgramData\Data4d\File4d.dat
ProgramData\Data5e\File5e.dat
AppData\Data6f\File6f.dat
AppData\Data7g\File7g1.dat
AppData\Data7g\File7g2.dat
Is there any way to do this with PA.com launcher?
Do they all need to be transferred prior to running the application for the first time, or just saved from run to run?
If it's the latter, use something like this in
[DirectoriesMove]SomeRandomFolderName1=%ALLUSERAPPDATA%\Data1a
SomeRandomFolderName2=%ALLUSERAPPDATA%\Data2b
SomeRandomFolderName3=%ALLUSERAPPDATA%\Data3c
SomeRandomFolderName4=%ALLUSERAPPDATA%\Data4d
SomeRandomFolderName5=%ALLUSERAPPDATA%\Data5e
SomeRandomFolderName6=%ALLUSERAPPDATA%\Data6f
SomeRandomFolderName7=%ALLUSERAPPDATA%\Data7g
Otherwise, if you only need those specific files, use
[FilesMove]instead.They don't need to be saved or backed up, they never will exist on the local machine prior to first run of this app and they are never modified.
They need to be moved to the AppData and ProgramData folders on the local machine before the app will run, as the app can't run without the presence of these files in their AppData folders, and moved back/deleted when the app exits.
In some of these folders, there are quite a lot of files. Should I use [FilesMove] method in this case?
Since the folders won't exist prior to first run, I recommend not including them in DefaultData, and including the necessary folder moves in the DirectoriesMove section.
By the way, you'll need to have elevated privileges to work with ProgramData, excuse me I meant AllUsersAppData.
daemon.devin
That's already handled by the launcher.
So you're telling me the Launcher knows automatically to run elevated? Lmao.
daemon.devin
I don't know if that is the case, but usually the dev should set RunAsAdmin if this folder is to be worked with for the app to work.
Thank you richo. That's all I was trying to say.
daemon.devin
Thank you all very much for you amazing support!
I was able to get my app working and (almost) fully portable using your advice.
My only problem is that the app leaves some trace behind and I can't fix it no matter what I do.
This happens only when I'm using
[FilesMove]to move files in place with deeper folder structure.I have code like this:
[FilesMove]
application.dat=%APPDATA%\Company\Application\Support Files\Data
The file "application.dat" and the folder "Data" is properly deleted/moved after the application exits, but the Company\Application\Support Files folders remain in place and no combination of
[DirectoriesCleanupIfEmpty]commands semms to help it.I have very similar issue with some registry keys within deeper structure. The value and the subkey gets properly deleted, but the parent keys stays in place and
[RegistryCleanupIfEmpty]doesn't help either.Can you, please, help me with this? Would be really grateful.
Can you show your [DirectoriesCleanupIfEmpty] section?
The above will only work if the folders are empty
So try doing this instead:
daemon.devin
Don't use
[DirectoriesCleanupForce]unless neither the Portable or Local version really care about this folder (e.g. temp or swap folders).If you just want to remove an empty directory, use
[DirectoriesCleanupIfEmpty].If the Local version may want to keep this folder, but you don't need to carry it around with the Portable version, use
[DirectoriesMove]with-as the source (e.g.-=%APPDATA%\Company\Application)To be entirely honest, I think you'd get better help if you told us what you're trying to make portable and stopped using placeholder information.
~3D1T0R
Well, if you read the manual, at least this is what I understood from it; you can use
[DirectoriesCleanupForce]safely as long as you[DirectoriesMove]with a-for a local backup like I had showed him in my example above.daemon.devin
That's not an "as well as", that's an "instead of".
You do one or the other, not both.
~3D1T0R
Than I would suggest removing the above line in the
[DirectoriesCleanupForce]section of the documentation as it is confusing. If I'm able to miss interpret this than others can be as well.daemon.devin
That should be reworded.
~3D1T0R
If you should only use one OR the other, remove that line from that section in the documentation. Do not reword it as
[DirectoriesMove]has nothing to do with[DirectoriesCleanupForce]in any instance as you put it.See, what I don't understand is why would Chris add that line in that section, not only that but dedicating it to it's own paragraph if it had nothing to do with that section? Especially, since the
[DirectoriesMove]section mentions this in it as well.It's misleading.
daemon.devin
It's there to tell people that if they want a similar but slightly different behaviour, it should be done using this alternative method instead of trying to find a workaround to force this method to do what they want.
It should however be reworded to show that it's an "instead" as opposed to an "as well".
~3D1T0R
I get it now. I'm just glad I didn't try teaching this method to anyone (the exception being my above comment) or explain that false topic on my website.
I understood it to be that way all these years.. Funny how something as little as that one sentence can be misinterpreted. Sorry for the misunderstanding.
daemon.devin
The thing with this app is that it stores nessesary DAT file and garbage temp data in the same folder.
[DirectoriesMove]command breaks any-=%APPDATA%\Company\Application
[FilesMove]commands that targets the same folder - the files just won't move and the app doesn't work properly.Sounds too complex for the likes of this PAL. You might need to try some real NSIS code so try using the
custom.nshfiledaemon.devin
Does anyone know if there's any particular reason for calling the
FilesMoveandDirectoriesMovesegments in the order (relative to each other) that they are?I would think that switching them would fix mnedo's issue. Would there be any ill effects if we did this?
Note: If you want to test this potential fix, open
Other\Source\PortableApps.comLauncher.nsi, find thePrePrimaryandPostPrimaryfunctions, then switch the lines that say${RunSegment} DirectoriesMoveand${RunSegment} FilesMovein each. You can then run the Launcher Generator as you normally would, and it'll use this version of the file.~3D1T0R
I m investigating whether there are any ill effects of this change. I suspect we should do some heavy testing prior to committing this to the official repo.
Consider the directory path %AppData%/a/b/c.
Current arrangement:
If file move is to %AppData%/a/b then follow by a directory move to %AppData%/a/b/c. No problem.
But if the directory move is to %AppData%/a, these will cause problem because directory a include sub-directory b.
For proposed arrangement:
If directory is to %AppData%/a/b and follow by a file move to %AppData%/a. No problem. But will cause problem if the file move is to %AppData%/a/b/c.
The above is refer to the preprimary segment.
So we can see if the path of file move and directory move are related. It may cause problem in either arrangement.
If mnedo not willing to let us know what he/she is actually want to do. It is difficult to help.
Sorry for my poor English. Hope you know what I want to say.
In
PrePrimary,FilesMovemoves files from the PortableDatadirectory to local locations, backing up local versions, andDirectoriesMovemoves directories (including files & subdirectories) to local locations, backing up local versions, unless the key is named-, in which case it only backs up the local version, as there's no Portable version to move.In
PostPrimary,FilesMovemoves files from their local locations to the PortableDatadirectory, restoring the local versions to their original place, andDirectoriesMovemoves directories from their local locations to the PortableDatadirectory, unless the key is-, in which case it discards them, in either case, it restores the local versions to their locations.Currently
PrePrimarycallsFilesMovefirst, thenDirectoriesMove, andPostPrimarycallsDirectoriesMovefirst, thenFilesMove. I'm suggesting we switch this so thatPrePrimarycallsDirectoriesMovefirst, thenFilesMove, andPostPrimarycallsFilesMovefirst, thenDirectoriesMove.Now... I'm having some difficulty keeping track of your examples, as you've written them rather sloppily, and I'm not sure why you have so many, but this is my best attempt at interpreting them:
In this case, there is no issue no matter whether
FilesMoveorDirectoriesMovehappens first, as they are simply next to each other, and won't be bothered by each other. The local version offilename.extwill be backed up, the Portable version will be moved appropriately, and the local version will be restored, likewise, the local version of%AppData%\a\b\cwill be backed up, the Portable version will be used & discarded as specified, and the local version will be restored. No conflictsIn this case, it currently causes the
%AppData%\adirectory and its contents to be discarded before%AppData%\a\b\filename.extgets moved back, causing the exact issue mnedo is having. If however,FilesMoveandDirectoriesMovewere switched, as I suggest, then%AppData%\a\b\filename.extwould be moved into the PortableDatadirectory, after which%AppData%\awould discarded, meaning thatfilename.extwould not be lost.Again, these will not interfere with each other whether the
FilesMove&DirectoriesMoveare switched or not.And again we're back to experiencing mnedo's current issue when using the current configuration, and no issue if they are switched.
~3D1T0R
After analyzed the examples, found that in the last example, filename.ext in %PAL:DataDir%\a\b\c is not the updated/edited one. The updated/edited ver. is in %PAL:DataDir%. But this do not cause issue as in next run the not-updated ver. will be replaced by the updated ver.
At least at the moment, I conclude that the proposed configuration is better than the current one.
Just to be clear, nowhere is the path "%PAL:DataDir%\a\b\c" mentioned at all.
We're discussing situations where the key name is
-, meaning that the Portable version of the folder will be discarded when the app closes, thus it currently losesfilename.extcompletely.If I'm understanding you correctly you're suggesting a situation such as this:
You should never do this, as the
DirectoriesMovesection will move the file%AppData%\a\b\c\filename.extto%PAL:DataDir%\a\b\c\filename.ext, and theFilesMovesection will also try to move it to%PAL:DataDir%\filename.ext.If however you did to do this, then assuming there are
filename.extfiles in all possible locations, with PAL the way it currently is, upon opening the app you would backup the local version of the file in the local version of the folder, replacing it with the Portable version referenced inFilesMove, then you would backup the local version of the folder (including the backed up local version and the Portable version referenced in yourFilesMove), replacing it with the version referenced byDirectoriesMove, meaning that%PAL:DataDir%\a\b\c\filename.extwould be the one you're using. Then upon closing the app you would move the version referenced byDirectoriesMoveback, replacing it with the backup of the folder, then you would move the unused version offilename.extback to%PAL:DataDir%\filename.extreplacing it with the original local version.In the end, there should be no issue, except that your
FilesMoveentry, and the file it references are pointless.Taking the same example, again assuming that there are
filename.extfiles in all locations, and running it with the suggested configuration would, upon opening the app, backup the local version of the folder, replacing it with the Portable version referenced inDirectoriesMove, then backup that version offilename.ext, replacing it with the version referenced inFilesMove, meaning that the version at%PAL:DataDir%\filename.extwould be the one you're using. Then upon closing the app it would move the version referenced byFilesMoveback, replacing it with the backup of the one in the folder referenced inDirectoriesMove, then move the folder referenced inDirectoriesMoveback, replacing it with the local version.Again, no real issue, but
%PAL:DataDir%\a\b\c\filename.extis now useless.Both of these situation end up with pointless moves and (a potential for) pointless backup files, and in both situation, the proper thing to do would be to drop the
FilesMoveentry, and simply use%PAL:DataDir%\a\b\c\filename.ext.The ONLY reason I can see for having a
FilesMovethat references a file inside aDirectoriesMovefolder, is when you're discarding the rest of the folder, but want to save that file, as mnedo is trying to do. Currently this is broken. My suggestion should fix it. Gord Caswell is investigating it to ensure it won't break anything.~3D1T0R
Thank you very much, this is brilliant idea. I'm curious if this gets officially supported by PorableApps.com.
I'm using
[DirectoriesCleanupForce](as Devin suggested) as a temporary hotfix, and the app now works exactly as expected. It is fine for my needs, but I understand why this solution can't be used in official release.I will try editing PortableApps.comLauncher.nsi and report back with results.
Glad I could help.
daemon.devin
When you say that "the app now works exactly as expected", does it backup and restore the local version of the directory, as an official app would need to do, or does it end up erasing the local data if it was present, as I believe DirectoriesCleanupForce is designed to do?
As to whether or not the "potential fix" I've posted will be used in a future official release of PAL... If it doesn't break anything, it most likely will. If it fixes this issue but breaks something else, it probably won't unless we can fix whatever that issue is.
~3D1T0R