FolderItem setting for CommonAppDataFolder

With WIndows / Vista / 7 / 8, shared application data is supposed to be stored in CommonAppDataFolder which translates to %SYSTEMDRIVE%\ProgramData. When I use the Xojo SpecialFolder.SharedApplicationData folderitem, it points to C:\ProgramData which “should” be correct for my systems. However, this path does not exist on any of my systems.

I’ve been scouring the MSDN site all morning and everyone says use it, but no one mentions that it’s not there by default.

2 Questions -

Are my Windows 7 and WIndows 8.1 system in bad shape?
or
Is it just expected that the first app that needs it creates it?

Now I’m red-faced. It’s there, but it’s hidden.

BTW if anyone is looking for the docs on Windows filesystem use, here’s the PDF:

VistaFileSysNamespaces.pdf

Tim watch your permissions on this. Unless elevated privileges are invoked you’ll only have read only access.

That’s what I’m battling right now. Do you have the details on creating my folders and setting the ACE/ACLs for general access? This is one of the elements of this that everyone complains about - it’s the “SHARED” app data folder, but it’s not SHARED…

Right now, I’m simply looking at:

theShell.Execute "attrib -r /S/D """ + SpecialFolder.Child("TOLIS Group").Child("BRU PE").NativePath + """"

I just gave up using it & created my own folder on the root of sysdrive.

Actually, it turns out that using that attrib command above after creating your folder makes it work properly.

Here’s what I now do:

When the app starts:
Check for the shared folder
If it doesn’t exist, check if we’re already running as admin

  • If not, tell the user to restart with “Run as Administrator”.
    On restart, create the folder(s) and execute that attrib command
    Show MsgBox telling the user to run as regular user
    Quit

Sometimes, the easy method is the best.

As usual, I spoke too soon. It turns out that I’ve become a victim of the disguised “Roaming” folder misdirection. All of my work was being placed into C:\Users\Tim\AppData\Roaming …

It looks like there’s no way around this without using an Installer and using the features of the installer app to create the TRUE C:\ProgrameData folders.

Okay - so even with the Innosetup use of Sharedappdata, the results are still not accessible by the normal user account. There’s some ACL magic that’s still required:

cacls "C:\\ProgramData\\Company Name" /T /G Users:F

Of course, company name is what you used for your app’s top level - for me, it’s C:\ProgramData\TOLIS Group\BRU PE. Setting the ACL state on the company folder with the /T option also sets the children and any files that they contain.

That will set the access privileges on your common app data hierarchy.

[quote=47191:@Tim Jones]Okay - so even with the Innosetup use of Sharedappdata, the results are still not accessible by the normal user account. There’s some ACL magic that’s still required:

cacls "C:\\ProgramData\\Company Name" /T /G Users:F

Of course, company name is what you used for your app’s top level - for me, it’s C:\ProgramData\TOLIS Group\BRU PE. Setting the ACL state on the company folder with the /T option also sets the children and any files that they contain.

That will set the access privileges on your common app data hierarchy.[/quote]

I know this a really old post but I was working on this issue myself today and noticed that Inno Setup was mentioned in this and there is a really easy way to set the permissions in the Inno Setup script that I thought I would add here.

Just add: Permissions: users-full; to your AppData folder entry. I put my program files in the program files folder and my DB file in the AppData folder with full permissions set via the installer. Works like a charm now I have read/write access to my SQLite DB under any user.

[Files] Source: "PathTo\\DB.rsd"; DestDir: "{commonappdata}\\Your Folder"; Flags: ignoreversion recursesubdirs; Permissions: users-full;