We are experiencing problems with run-time virtualization that Windows Vista does when files are changed in C:\ProgramData. This is painful and annoying but it might be that it's because I haven't really understood how the system is meant to use.

My understanding is that I put my application data into the folder that I retrieve by reading CSIDL_LOCAL_APPDATA. For Vista this yields C:\ProgramData. Unfortunately on some occasions Windows switches into some obscure compatibility mode and virtualizes files and puts them in different locations. Sometimes you'll get really strange behaviour because you never know which file you're using: real or virtual.I also haven't understood when Vista does that. I reckon it has something to do with access rights but I am not sure.

Therefore, I really would like to get an official white paper or documentation or guideline or best practice where it is explained how developers should organize their data files. So, if any of you guys know a URL where I can find more information about that topic I would be glad if you could share that with us.

Regards,

Dirk.

Dirk,

Additional weird behavior I've run into (but can't confirm 100%) is that Vista decides whether or not to virtualize files depending on whether or not your app writes to them, or only reads them.

So if you have a bunch of files and some are modified by your code and some aren't, the modified ones end up ain a different place in the file system than the ones that weren't modified.

Adam Leffert

Here is my really quick guess: Vista virtualizes FS when you don't have privileges to write in to a protected folder. ProgramData sounds to me like a protected folder if you don't have some sort of elevated privileges.

Hmm, I thought C:\ProgramData has been invented to provide a place where applications write their data to. Where is an application supposed to write non-temporary data to if not to C:\ProgramData? When a non-admin user runs the app it should be able to write data to the disc.

Isn't there any official guideline how to handle that?

Can you use IsolatedStorage?

Hi,

Many many months ago I looked for the same thing and asked in various forums for guidance. Almost every response was either irrelevant or ended up with Vista UAC bashing.

I have only recently felt comfortable with all the hoopla in regards to Vista and the UAC and can see where MS are/were coming from.

The white paper you are looking for consists only of one or two lines and can be condensed even further....

Previous to Vista, the All Users data folder was writable by all. Since Vista, it is not. The same applies to the Registry.

There you go - your white paper. [I can't help to make a swipe at someone here - IA would actually publish that and get snotty if anyone complained ]

Now I can't help you with how MS manages it's UAC features but I guess they virtualize everything so they can return the status quo if necessary.

I can tell you how I resolved the problem of using the All Users data folder the same way in Vista as I did before Vista. After testing to see if the user OS was indeed Vista I called the following and passed in the appropriate directory. The program that includes this code must be running with elevated privledges.

#region Process - Set Vista Permissions
    private void setPermissions(string dir)
    {
      if (dir.EndsWith(Path.DirectorySeparatorChar.ToString()))
      {
        dir = dir.Remove(dataDirectory.Length - 1);
      }

      //in spanish builtin\Usuarios.. If your culture is important , not all builtin users are specified in English so use the SID instead...
      SecurityIdentifier sid = new SecurityIdentifier(WellKnownSidType.BuiltinUsersSid, null);
      NTAccount acct = (NTAccount)sid.Translate(typeof(NTAccount));

      try
      {
        DirectoryInfo info = new DirectoryInfo(dir);
        DirectorySecurity ds = info.GetAccessControl();
        ds.AddAccessRule(new FileSystemAccessRule(acct,
                         FileSystemRights.FullControl,
                         InheritanceFlags.ObjectInherit |
                         InheritanceFlags.ContainerInherit,
                         PropagationFlags.None,
                         AccessControlType.Allow));
        info.SetAccessControl(ds);
        logger.Fatal("Set Vista access rights successfully");
      }
      catch (Exception ex)
      {
        logger.FatalException("Failed to set Vista access rights : ", ex);
      }

      if (!Directory.Exists(@"C:\Windows\Microsoft.Net\Framework\V2.0.50727\Temporary ASP.NET Files\"))
      {
        try
        {
          Directory.CreateDirectory(@"C:\Windows\Microsoft.Net\Framework\V2.0.50727\Temporary ASP.NET Files\");
          logger.Fatal("Created ASP.NET temp directory");
        }
        catch(Exception ex)
        {
          logger.FatalException("Unable to create ASP.NET Temp directory: ", ex);
        }
      }

The ASP.Net bit at the end is because when I enabled IIS6 in Vista the directory wasn't created.

I do have a separate configuration program that ammends the Registry where required but I figured that the UAC really wasn't a bad idea when it came to playing with the registry so I amended the manifest created by VS2008 requiring extra privledges to run. At least the end users can decide who's going to stuff things up instead of me automating it for them .

After including the above, I have been able to virtually forget about the Vista woes and code without worrying about OS..

The short answer to your question is therefor - "The same place as before."