You are here

How to handle CommonAppData aka All Users AppData aka C:\ProgramData?

38 posts / 0 new
Last post
mnedo
Offline
Last seen: 7 years 1 month ago
Joined: 2017-08-22 05:13
How to handle CommonAppData aka All Users AppData aka C:\ProgramData?

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]?

Gord Caswell
Gord Caswell's picture
Offline
Last seen: 1 week 2 hours ago
DeveloperModerator
Joined: 2008-07-24 18:46
ALLUSERSAPPDATA

You're looking for the ALLUSERSAPPDATA environment variable.

See here: https://portableapps.com/manuals/PortableApps.comLauncher/ref/envsub.htm...

demon.devin
demon.devin's picture
Offline
Last seen: 4 years 1 month ago
Developer
Joined: 2007-08-02 09:04
Alternatively you could use

Alternatively you could use custom.nsh

SetShellVarContext all
StrCpy $0 $APPDATA
${SetEnvironmentVariablesPath} PROGRAMDATA $0
SetShellVarContext current

Now 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

3D1T0R
3D1T0R's picture
Offline
Last seen: 3 years 2 months ago
Developer
Joined: 2006-12-29 23:48
Why would you bother to do this when a better solution exists.

Just use %AllUsersAppData%, its tested, documented, and already there. No need for a Custom.nsh which would require rebuilding the launcher to include.

~3D1T0R

mnedo
Offline
Last seen: 7 years 1 month ago
Joined: 2017-08-22 05:13
Thank you very much for your

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 Sad

Gord Caswell
Gord Caswell's picture
Offline
Last seen: 1 week 2 hours ago
DeveloperModerator
Joined: 2008-07-24 18:46
First option, sort of

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\AppNameConfig to %ALLUSERSAPPDATA%\Data3c.
As such, if you need anything to be in that folder by default, you need to include that data in \DefaultData\AppNameConfig.

mnedo
Offline
Last seen: 7 years 1 month ago
Joined: 2017-08-22 05:13
Ah, now it makes sense! Thank

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?

Gord Caswell
Gord Caswell's picture
Offline
Last seen: 1 week 2 hours ago
DeveloperModerator
Joined: 2008-07-24 18:46
Simple

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.

mnedo
Offline
Last seen: 7 years 1 month ago
Joined: 2017-08-22 05:13
They don't need to be saved

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?

Gord Caswell
Gord Caswell's picture
Offline
Last seen: 1 week 2 hours ago
DeveloperModerator
Joined: 2008-07-24 18:46
Directories vs Files

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.

demon.devin
demon.devin's picture
Offline
Last seen: 4 years 1 month ago
Developer
Joined: 2007-08-02 09:04
By the way, you'll need to

By the way, you'll need to have elevated privileges to work with ProgramData, excuse me I meant AllUsersAppData.

daemon.devin

Gord Caswell
Gord Caswell's picture
Offline
Last seen: 1 week 2 hours ago
DeveloperModerator
Joined: 2008-07-24 18:46
Already done

That's already handled by the launcher.

demon.devin
demon.devin's picture
Offline
Last seen: 4 years 1 month ago
Developer
Joined: 2007-08-02 09:04
So you're telling me the

So you're telling me the Launcher knows automatically to run elevated? Lmao.

daemon.devin

richo
richo's picture
Offline
Last seen: 5 months 6 days ago
Joined: 2007-01-31 22:03
re: So you're telling me the

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.

demon.devin
demon.devin's picture
Offline
Last seen: 4 years 1 month ago
Developer
Joined: 2007-08-02 09:04
Thank you richo. That's all I

Thank you richo. That's all I was trying to say.

daemon.devin

mnedo
Offline
Last seen: 7 years 1 month ago
Joined: 2017-08-22 05:13
Thank you all very much for

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. Smile

JLim
Offline
Last seen: 5 months 2 days ago
Joined: 2013-07-17 01:30
Can you show your

Can you show your [DirectoriesCleanupIfEmpty] section?

demon.devin
demon.devin's picture
Offline
Last seen: 4 years 1 month ago
Developer
Joined: 2007-08-02 09:04
[DirectoriesCleanupIfEmpty]
[DirectoriesCleanupIfEmpty]
1=%APPDATA%\Company\Application\Support Files
2=%APPDATA%\Company\Application
3=%APPDATA%\Company

The above will only work if the folders are empty

So try doing this instead:

[DirectoriesMove]
-=%APPDATA%\Company

[DirectoriesCleanupForce]
1=%APPDATA%\Company\Application\Support Files
2=%APPDATA%\Company\Application
3=%APPDATA%\Company

daemon.devin

3D1T0R
3D1T0R's picture
Offline
Last seen: 3 years 2 months ago
Developer
Joined: 2006-12-29 23:48
Don't use

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

demon.devin
demon.devin's picture
Offline
Last seen: 4 years 1 month ago
Developer
Joined: 2007-08-02 09:04
Well, if you read the manual,

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

3D1T0R
3D1T0R's picture
Offline
Last seen: 3 years 2 months ago
Developer
Joined: 2006-12-29 23:48
You're reading it wrong.

That's not an "as well as", that's an "instead of".
You do one or the other, not both.

~3D1T0R

demon.devin
demon.devin's picture
Offline
Last seen: 4 years 1 month ago
Developer
Joined: 2007-08-02 09:04
If you need to back up the

If you need to back up the local directory so that it will not be ruined, you can use [DirectoriesMove] with a key name of -.

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

3D1T0R
3D1T0R's picture
Offline
Last seen: 3 years 2 months ago
Developer
Joined: 2006-12-29 23:48
That should be reworded.

That should be reworded.

~3D1T0R

demon.devin
demon.devin's picture
Offline
Last seen: 4 years 1 month ago
Developer
Joined: 2007-08-02 09:04
Remove it altogether.

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

3D1T0R
3D1T0R's picture
Offline
Last seen: 3 years 2 months ago
Developer
Joined: 2006-12-29 23:48
It's an alternative.

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

demon.devin
demon.devin's picture
Offline
Last seen: 4 years 1 month ago
Developer
Joined: 2007-08-02 09:04
Understood

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

mnedo
Offline
Last seen: 7 years 1 month ago
Joined: 2017-08-22 05:13
The thing with this app is

The thing with this app is that it stores nessesary DAT file and garbage temp data in the same folder. [DirectoriesMove]
-=%APPDATA%\Company\Application
command breaks any [FilesMove] commands that targets the same folder - the files just won't move and the app doesn't work properly.

demon.devin
demon.devin's picture
Offline
Last seen: 4 years 1 month ago
Developer
Joined: 2007-08-02 09:04
custom.nsh it then

Sounds too complex for the likes of this PAL. You might need to try some real NSIS code so try using the custom.nsh file

daemon.devin

3D1T0R
3D1T0R's picture
Offline
Last seen: 3 years 2 months ago
Developer
Joined: 2006-12-29 23:48
This may be a bug in PAL.

Does anyone know if there's any particular reason for calling the FilesMove and DirectoriesMove segments 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 the PrePrimary and PostPrimary functions, then switch the lines that say ${RunSegment} DirectoriesMove and ${RunSegment} FilesMove in each. You can then run the Launcher Generator as you normally would, and it'll use this version of the file.

~3D1T0R

Gord Caswell
Gord Caswell's picture
Offline
Last seen: 1 week 2 hours ago
DeveloperModerator
Joined: 2008-07-24 18:46
Investigating

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.

JLim
Offline
Last seen: 5 months 2 days ago
Joined: 2013-07-17 01:30
Consider the directory path

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.

3D1T0R
3D1T0R's picture
Offline
Last seen: 3 years 2 months ago
Developer
Joined: 2006-12-29 23:48
You may be misunderstanding what's happening here.

In PrePrimary, FilesMove moves files from the Portable Data directory to local locations, backing up local versions, and DirectoriesMove moves 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, FilesMove moves files from their local locations to the Portable Data directory, restoring the local versions to their original place, and DirectoriesMove moves directories from their local locations to the Portable Data directory, unless the key is -, in which case it discards them, in either case, it restores the local versions to their locations.

Currently PrePrimary calls FilesMove first, then DirectoriesMove, and PostPrimary calls DirectoriesMove first, then FilesMove. I'm suggesting we switch this so that PrePrimary calls DirectoriesMove first, then FilesMove, and PostPrimary calls FilesMove first, then DirectoriesMove.

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:

[FilesMove]
filename.ext=%AppData%\a\b

[DirectoriesMove]
-=%AppData%\a\b\c

In this case, there is no issue no matter whether FilesMove or DirectoriesMove happens first, as they are simply next to each other, and won't be bothered by each other. The local version of filename.ext will 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\c will be backed up, the Portable version will be used & discarded as specified, and the local version will be restored. No conflicts

[FilesMove]
filename.ext=%AppData%\a\b

[DirectoriesMove]
-=%AppData%\a

In this case, it currently causes the %AppData%\a directory and its contents to be discarded before %AppData%\a\b\filename.ext gets moved back, causing the exact issue mnedo is having. If however, FilesMove and DirectoriesMove were switched, as I suggest, then %AppData%\a\b\filename.ext would be moved into the Portable Data directory, after which %AppData%\a would discarded, meaning that filename.ext would not be lost.

[FilesMove]
filename.ext=%AppData%\a

[DirectoriesMove]
-=%AppData%\a\b

Again, these will not interfere with each other whether the FilesMove & DirectoriesMove are switched or not.

[FilesMove]
filename.ext=%AppData%\a\b\c

[DirectoriesMove]
-=%AppData%\a\b

And again we're back to experiencing mnedo's current issue when using the current configuration, and no issue if they are switched.

~3D1T0R

JLim
Offline
Last seen: 5 months 2 days ago
Joined: 2013-07-17 01:30
After analyzed the examples,

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.

richo
richo's picture
Offline
Last seen: 5 months 6 days ago
Joined: 2007-01-31 22:03
re: After analyzed the examples

Just to be clear, nowhere is the path "%PAL:DataDir%\a\b\c" mentioned at all.

3D1T0R
3D1T0R's picture
Offline
Last seen: 3 years 2 months ago
Developer
Joined: 2006-12-29 23:48
Different situation.

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 loses filename.ext completely.

If I'm understanding you correctly you're suggesting a situation such as this:

[FilesMove]
filename.ext=%AppData%\a\b\c

[DirectoriesMove]
a=%AppDir%\a

You should never do this, as the DirectoriesMove section will move the file %AppData%\a\b\c\filename.ext to %PAL:DataDir%\a\b\c\filename.ext, and the FilesMove section will also try to move it to %PAL:DataDir%\filename.ext.

If however you did to do this, then assuming there are filename.ext files 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 in FilesMove, then you would backup the local version of the folder (including the backed up local version and the Portable version referenced in your FilesMove), replacing it with the version referenced by DirectoriesMove, meaning that %PAL:DataDir%\a\b\c\filename.ext would be the one you're using. Then upon closing the app you would move the version referenced by DirectoriesMove back, replacing it with the backup of the folder, then you would move the unused version of filename.ext back to %PAL:DataDir%\filename.ext replacing it with the original local version.
In the end, there should be no issue, except that your FilesMove entry, and the file it references are pointless.

Taking the same example, again assuming that there are filename.ext files 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 in DirectoriesMove, then backup that version of filename.ext, replacing it with the version referenced in FilesMove, meaning that the version at %PAL:DataDir%\filename.ext would be the one you're using. Then upon closing the app it would move the version referenced by FilesMove back, replacing it with the backup of the one in the folder referenced in DirectoriesMove, then move the folder referenced in DirectoriesMove back, replacing it with the local version.
Again, no real issue, but %PAL:DataDir%\a\b\c\filename.ext is 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 FilesMove entry, and simply use %PAL:DataDir%\a\b\c\filename.ext.

The ONLY reason I can see for having a FilesMove that references a file inside a DirectoriesMove folder, 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

mnedo
Offline
Last seen: 7 years 1 month ago
Joined: 2017-08-22 05:13
Thank you very much, this is

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.

demon.devin
demon.devin's picture
Offline
Last seen: 4 years 1 month ago
Developer
Joined: 2007-08-02 09:04
Glad I could help.

Glad I could help.

daemon.devin

3D1T0R
3D1T0R's picture
Offline
Last seen: 3 years 2 months ago
Developer
Joined: 2006-12-29 23:48
Define "exactly as expected"...

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

Log in or register to post comments