4

I have a Visual Basic 6.0 application that I want to install for All Users, for example, the setting are held in a single spot regardless who logs into the computer. I have the following code to locate the common location:

Const ssfCOMMONAPPDATA = &H23
Dim strAllUsersPath As String

strAllUsersPath = CreateObject("Shell.Application").NameSpace(ssfCOMMONAPPDATA).Self.Path

On Windows XP, this path points to C:\Documents and Settings\All Users\Application Data\ folder. The setup copies the settings file there and everything is great. The Visual Basic 6.0 app can change it at any time.

On Windows 7, this path points to c:\ProgramData folder. The setup, which requires administrator privileges, copies the file there. However, when my Visual Basic 6.0 application starts and accesses the file, Windows 7 copies the settings file to a C:\Users{USER LOGIN}\AppData\Local\VirtualStore\ and performs all the operations on it there. As a result, because for each user, Windows 7 copies the settings file to a separate user directory, the users end up having a different settings file.

Am I storing the file in the wrong location? Am I doing it in the incorrect manner?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
AngryHacker
  • 59,598
  • 102
  • 325
  • 594
  • [A question and two answers](http://stackoverflow.com/questions/3219255/why-do-files-get-placed-c-users-usernameappdata-local-virtualstore-program-fi) that could be of interest – Steve May 08 '12 at 22:14

1 Answers1

10

This one has bitten me too. The ProgramData folder has shared Read Access, no shared write access. You can of course change the permission on the folder during install, but I think that goes contrary to how Microsoft meant it to be. See this other question for some useful links

How Microsoft thinks it should be done.

Community
  • 1
  • 1
Dabblernl
  • 15,831
  • 18
  • 96
  • 148
  • +1 Microsoft don't want you to write to `COMMONAPPDATA`. Here's a [nice VB6 article by Karl Peterson](http://vb.mvps.org/articles/vsm20090119.pdf) on the subject of where to store settings. And [this VB6 question](http://stackoverflow.com/questions/3054802/commonappdata-in-vb6) – MarkJ May 09 '12 at 08:02
  • @MarkJ This article says it all very well indeed. I am using his CSystemFolders class in my VB6 app for more than a year now without any hickups (2500 users) – Dabblernl May 09 '12 at 08:13
  • 4
    ProgramData doesn't have "shared" anything access. CommonAppData is perfectly fine and is *recommended* and *preferred* by Microsoft for, well, common app data - as the name suggests. The snag is your installer should create the app's subfolder there and set appropriate security on it to permit required access (often you want Full Control for Users). By default files and folders are created there with *owner* access. I'd be cautious about anything from Karl, he often broad-brushes things and misses the fine points - but none of us is perfect. – Bob77 May 09 '12 at 12:44
  • 2
    You can also do a "first run" check then elevate and create the subfolder structure and set security if your installer isn't up to this. – Bob77 May 09 '12 at 12:57
  • 1
    This is a problem in Windows 8 as well - just uncovered it today. Not sure how it ever evaded us in Windows 7? – jocull Jan 10 '13 at 19:01
  • The permissions on the ProgramData folder are not read-only. Any user can create a file or directory, without elevating. – Harry Johnston Dec 16 '14 at 07:25
  • 3
    The link `How Microsoft thinks it should be done.` is broken – yukashima huksay May 09 '19 at 05:38
  • The link was for a [download page](https://web.archive.org/web/20120508160635/http://www.microsoft.com/en-us/download/details.aspx?id=3859) for a [PDF](https://web.archive.org/web/20120601184745/http://download.microsoft.com/download/1/E/9/1E9580D9-2B2B-499C-918A-C9BA5EAC4A32/Windows%207%20Client%20Software%20Logo.pdf) and [XPS](https://web.archive.org/web/20120525075745/http://download.microsoft.com/download/1/E/9/1E9580D9-2B2B-499C-918A-C9BA5EAC4A32/Windows%207%20Client%20Software%20Logo.xps), which luckily have been successfully captured on web.archive.org. – Gian Singh Sarao May 26 '22 at 17:08