C# - Vista - Decompression being virtualized when using CommonApplicationData

Question

Assume UAC is ON. This does not create a problem with it off.

I have a c# app with a backup/restore functionality and using sql server 2005 express.

code to get the backupPath is used for both backup and restore and the name for all purposes will be backup.dat

to generate backup path

string path = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData);
 path = Path.Combine(path, "CompName");
 if(!Directory.Exists(path))
        Directory.CreateDirectory(path);
 path = Path.Combine(path, "AppName");
 if(!Directory.Exists(path))
        Directory.CreateDirectory(path);
 return path;

On backup the db generates backup.dat in *C:\ProgramData\CompName\AppName* and it has no difficulty zipping from that location to a target directory of the users choice.

On restore it has no problem getting the archived directory or the file but when it decompresses it goes to *C:\Users\UserName\AppData\Local\VirtualStore\ProgramData\CompName\AppName*

I need to know why my decompressed file is going to a virtual store so I can restore the db because from what I understand of programming for vista sql server should not / won't be able to access that virtual store path.

edit: failed to provide with decompression - I don't think this is the problem but here it is.

private void DecompressArchiveFile(string compressedFile, string backupPath)
{
    GZipStream gzip = new GZipStream(new FileStream(compressedFile, FileMode.Open, FileAccess.Read, FileShare.None), CompressionMode.Decompress, false);
    FileStream fs = new FileStream(backupPath, FileMode.Create, FileAccess.Write, FileShare.None);

    byte[] buffer = new byte[10000];
    int count = -1;
    while (count != 0)
    {
     count = gzip.Read(buffer, 0, 10000);
     fs.Write(buffer, 0, count);
    }
    gzip.Close();
    fs.Close();
}

Thanks for any and all help -TK

Answer 1

I think you're hitting the Vista Virtualization feature - it is meant to keep old badly behaved apps from not working on Vista where they are not allowed to write to %ProgramData%.

Your app can read from %ProgramData% but not write to it. If you really want to write under %ProgramData% you have to run elevated (or change the DACL on the subpath to let you write).

See http://technet.microsoft.com/en-us/magazine/cc160980.aspx (Data Redirection) for more details.

Answer 2

See this related Stack Overflow question, in particular from the link from this answer:

FOLDERID_ProgramData / System.Environment.SpecialFolder.CommonApplicationData

The user would never want to browse here in Explorer, and settings changed here should affect every user on the machine. The default location is %systemdrive%\ProgramData, which is a hidden folder, on an installation of Windows Vista. You'll want to create your directory and set the ACLs you need at install time.

So if you intend your users to be able to write to this folder you'll have to give them appropriate access when your installer runs.

If they have write access to the folder then I don't think you'll run into problems with the virutalisation. However, you should really mark your application with the privilege level it requires by adding something like this to your manifest (details):

<security>
  <requestedPrivileges>
    <requestedExecutionLevel level="asInvoker" />
  </requestedPrivileges>
</security>

This will disable virtualisation for your process. You can see whether your process is being virtualised by adding the "Virtualization" column to Task Manager under View - Select Columns...

Incidentally, Directory.CreateDirectory() will create parent directories automatically.