Impossible de créer des fichiers dans C:\ProgramData\ même après l'octroi de groupe Utilisateurs avec la permission

Nous avons une application qui tente d'écrire dans une base de données Access (.mdb) dans le C:\ProgramData\ dossier. Sur les ordinateurs avec l'UAC activé, nous trouvons que l'accès à la base de données échoue il semble qu'il ne peut pas créer le fichier de verrouillage. Il semble que par défaut (et peut-être en raison de contrôle de compte d'utilisateur) utilisateurs (y compris les admins) n'ont pas l'autorisation d'écrire dans le dossier applications par défaut.

Nous avons pensé que l'octroi du groupe "Users" toutes les autorisations sur ce dossier serait résoudre le problème, mais il ne fait aucune différence. Même l'octroi de "tout le monde" contrôle total n'aide pas. La seule chose qui résout le problème semble être de déplacer la base de données dans un autre dossier (par exemple C:\applicationname) qui n'est pas le meilleur de la pratique OU de l'exécution de l'application avec des privilèges d'Administrateur en changeant le raccourci.

Comment pouvons-nous faire en sorte que les utilisateurs normaux peuvent écrire (et de créer des fichiers) dans le C:\ProgramData\ dossier? Ou sommes-nous en abusant de ce dossier? J'étais sous l'impression que c'est la bonne place pour mettre partagé les données du programme (pour tous les utilisateurs) et de nombreuses autres applications semblent avoir mis leurs données sur mon ordinateur.

Mise à jour:

J'ai trouvé que un clone copie de la base de données a été mis en dossier suivant:
C:\Users\\AppData\Local\VirtualStore\ProgramData\

Si je supprime ce dossier, l'application effectue ensuite normalement. Pourquoi ce dossier a été créé? Puis-je éviter cela en quelque sorte? Serait-ce parce que l'installateur n'est pas de donner des autorisations pour le groupe d'Utilisateurs sur le dossier dans C:\ProgramData\ ?

Je suis incapable de recréer votre problème. J'ai créé le dossier "C:\ProgramData\myApp\" à l'aide de mon "Administrateurs" compte et avec les autorisations par défaut "Utilisateurs" a un accès en lecture seule. Cependant, une fois que j'ai accordé à "Modifier" les autorisations sur le dossier ensuite, ils pourraient ouvrir la base de données et créer le fichier de verrouillage.
Je ne peux pas le reproduire sur ma propre machine, mais je PEUX le reproduire sur deux machines de test et sur l'ordinateur d'un client. Je ne suis pas sûr de ce que sont les différences entre les ordinateurs comme les autorisations de dossier semble identique à moi.

OriginalL'auteur NickG | 2014-11-07

  1. 4

    Serait-ce parce que l'installateur n'est pas de donner des autorisations pour le groupe d'Utilisateurs sur le dossier dans C:\ProgramData\ ?

    En fait, il est plus probable que le programme d'installation n'a pas ont autorisations suffisantes pour salir "C:\ProgramData\" directement. (Je pensée que ce scénario semblait familier....)

    Lorsque Microsoft a présenté Contrôle de compte d'utilisateur ils avaient besoin d'un moyen pour les anciennes applications de continuer à travailler, au moins pour un temps. Ce qu'ils ont créé a été "Fichiers de Registre et de la virtualisation", où l'héritage des applications que vous tentez d'accéder (aujourd'hui)verboten dossiers Système ou des entrées de registre serait redirigé vers leur propre spécifiques à l'utilisateur "virtualisé" copie de ces ressources. Comme l'article de Wikipédia sur Contrôle de compte d'utilisateur le décrit:

    Les Applications écrites avec l'hypothèse que l'utilisateur sera exécuté avec des privilèges d'administrateur connu des problèmes dans les versions antérieures de Windows lorsque vous exécutez à partir des comptes utilisateurs limités, souvent parce qu'ils ont tenté d'écrire à la machine ou à l'échelle du système des répertoires (comme Fichiers de Programme) ou des clés de registre (notamment HKLM).[4] contrôle de compte d'utilisateur tente d'atténuer ce à l'aide de de Fichiers et de Registre de Virtualisation, qui redirige l'écrit (et les lectures suivantes) par l'emplacement de l'utilisateur dans le profil de l'utilisateur. Par exemple, si une application tente d'écrire dans un répertoire comme "C:\Program Files\appname\paramètres.ini" à laquelle l'utilisateur n'a pas la permission d'écriture, l'écriture sera redirigé vers "C:\Users\username\AppData\Local\VirtualStore\Program Files\appname\paramètres.ini". La fonctionnalité de redirection n'est prévue pour les non-élévation des applications 32 bits, et que si ils ne comprennent pas un manifeste que les demandes de privilèges spécifiques.[13]

    Si votre installateur demandes "Exécuter en tant qu'administrateur" privilèges alors vous devriez être en mesure d'éviter ce problème.

    Donc, si le programme d'installation donne à l'C:\programData\appname dossier de l'Utilisateur des autorisations d'écriture, qui va empêcher le "clone" copie en cours de création dans VirtualStore? (et donc de résoudre le problème?)
    Il devrait, si le programme d'installation s'exécute avec des privilèges élevés, car le programme d'installation serait la création d'un réel "nom\" dossier à la place de virtualiser un, puis par l'application d'autorisations suffisantes afin que les autres utilisateurs peuvent avoir accès en lecture/écriture à un "vrai" dossier.
    Est votre modifier certainement correct? Comment un installateur avez pas les autorisations? Si elle n'a pas exécuter en tant qu'admin, il ne serait pas en mesure d'installer l'application. Ou suis-je malentendu?
    Cela dépendrait de ce que précisément le programme d'installation est en train de faire. Le plus "normal", les installateurs ont besoin pour s'exécuter avec des privilèges élevés (et donc de déclencher une invite UAC, même lorsqu'il est exécuté à partir d'un compte qui est membre du groupe "Administrateurs"), mais dans votre cas particulier, il peut tout simplement avoir exécuté avec les privilèges de l'utilisateur qui a lancé le programme d'installation.
    Le programme d'installation s'exécute en tant qu'utilisateur admin. Bizarrement, maintenant, je ne peux pas reproduire le problème, donc je suis encore très confus au sujet de exactement ce qui la provoque. Si j'essaie de le repro-il maintenant, la base de données les fichiers de verrouillage simplement créé dans le VirtualStore et l'application fonctionne très bien.

    OriginalL'auteur Gord Thompson