C# - Vista - Décompression virtualisée lors de l'utilisation de CommonApplicationData

Question

Supposons que l'UAC soit activé.Cela ne crée pas de problème avec sa désactivation.

J'ai une application C# avec une fonctionnalité de sauvegarde/restauration et j'utilise SQL Server 2005 Express.

le code pour obtenir le chemin de sauvegarde est utilisé à la fois pour la sauvegarde et la restauration et le nom à toutes fins sera backup.dat

pour générer un chemin de sauvegarde

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;

Lors de la sauvegarde, la base de données génère backup.dat dans **C:\ProgramData\CompName\AppName** et elle n'a aucune difficulté à compresser depuis cet emplacement vers un répertoire cible au choix de l'utilisateur.

Lors de la restauration, il n'a aucun problème à obtenir le répertoire archivé ou le fichier, mais lorsqu'il est décompressé, il va dans **C:\Users\UserName\AppData\Local\VirtualStore\ProgramData\CompName\AppName**

J'ai besoin de savoir pourquoi mon fichier décompressé va dans un magasin virtuel afin de pouvoir restaurer la base de données, car d'après ce que je comprends de la programmation pour le serveur Vista SQL, il ne devrait pas/ne pourra pas accéder à ce chemin de magasin virtuel.

modifier:n'a pas réussi à assurer la décompression - je ne pense pas que ce soit le problème, mais le voici.

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();
}

Merci pour toute aide -tk

Answer 1

Voir ce débordement de pile associé question, notamment du lien de ceci répondre:

Folderid_programData / System.environment.SpecialFolder.CommonApplicationData

L'utilisateur ne voudrait jamais parcourir ici dans Explorer, et les paramètres modifiés ici devraient affecter chaque utilisateur de la machine.L'emplacement par défaut est% SystemDrive% ProgramData, qui est un dossier caché, sur une installation de Windows Vista. Vous voudrez créer votre répertoire et définir les ACL dont vous avez besoin au moment de l'installation.

Donc, si vous souhaitez que vos utilisateurs puissent écrire dans ce dossier, vous devrez leur accorder un accès approprié lors de l'exécution de votre programme d'installation.

S'ils ont un accès en écriture au dossier, je ne pense pas que vous rencontrerez des problèmes avec la virtualisation.Cependant, vous devez vraiment marquer votre application avec le niveau de privilège dont elle a besoin en ajoutant quelque chose comme ceci à votre manifeste (détails):

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

Cela désactivera la virtualisation de votre processus.Vous pouvez voir si votre processus est virtualisé en ajoutant la colonne "Virtualisation" au Gestionnaire des tâches sous Affichage - Sélectionner les colonnes...

Par ailleurs, Directory.CreateDirectory() créera automatiquement les répertoires parents.

Answer 2

Je pense que vous frappez la fonctionnalité Vista virtualisation -. Il est censé conserver les anciennes applications mal comportés de ne pas travailler sur Vista où ils ne sont pas autorisés à écrire% ProgramData%

Votre application peut lire% ProgramData% mais pas écrire. Si vous voulez vraiment écrire sous% ProgramData% que vous avez à courir élevé (ou modifier le DACL sur le sous-chemin pour vous permettre d'écrire).

Voir http://technet.microsoft.com/en-us/ magazine / cc160980.aspx (Redirection de données) pour plus de détails.