Question

dans mon application, je dois stocker les paramètres "globaux" (c'est-à-dire non spécifiques à l'utilisateur) dans un emplacement connu et prévisible.

Je souhaite que l'application puisse être exécutée à partir de n'importe où (en tant qu'utilisateur standard, PAS en tant qu'administrateur), y compris plusieurs copies à partir de différents emplacements et pour pouvoir lire et écrire les fichiers de configuration enregistrés.

Les données doivent disposer d'un accès en lecture et en écriture accordé à TOUS les utilisateurs standard, et non un seul.

Dans cet esprit, les quatre options mentionnées ici sont inappropriées: http://msdn.microsoft.com/en -us / library / bb206295 (VS.85) .aspx # ID0E1BA

Alors, quelles sont mes alternatives?

Mon application est écrite en C ++ et pour Windows uniquement. Je dois prendre en charge Windows XP et les versions ultérieures.

Merci.

EDIT:

Pour clarifier, ignorez les conditions de concurrence causées par plusieurs instances. Cette question concerne uniquement l’emplacement de stockage des données. Je ne vois nulle part où cela convient:

  1. Prévisible (par exemple,% APPDATA% \ Foo est un chemin "prévisible", mais malheureusement spécifique à l'utilisateur)
  2. Global (par exemple,% PROGRAMDATA% \ Foo est un chemin global mais, malheureusement, seul l'utilisateur qui crée le fichier a un accès en écriture)
  3. Accessible (un utilisateur standard doit pouvoir créer de nouveaux fichiers dans le répertoire donné, cela s'applique à tous les utilisateurs du système)
Était-ce utile?

La solution

Si vous décidez que CSIDL_COMMON_APPDATA n'est pas approprié (HKLM\SOFTWARE\<your app subkey> est peut-être un bon choix par défaut, mais vous souhaitez que l'administrateur puisse modifier l'emplacement), vous pouvez demander au programme d'installation d'écrire quelque chose dans un <=> qui indique le chemin souhaité pour le répertoire commun qui contiendra les données.

Une alternative au placement du pointeur dans le registre HKLM consiste à avoir un fichier de configuration résidant dans le répertoire du programme contenant un pointeur sur le répertoire partagé. Par définition, le répertoire du programme doit être accessible en écriture par le programme d'installation, pour les administrateurs (éventuellement responsable de la modification de la configuration) et en lecture par les utilisateurs. Ainsi, un utilisateur standard peut lire un emplacement connu (une sous-clé HKLM ou un fichier de configuration dans le répertoire du programme) pour obtenir un pointeur sur un répertoire accessible en écriture par tous les utilisateurs standard.

Quelle que soit la configuration du répertoire commun (programme d'installation ou module de configuration), vous devez vous assurer que la liste de contrôle d'accès du répertoire commun est correctement définie pour les écritures utilisateur standard.

Autres conseils

Essayez le dossier Public dans le répertoire des profils utilisateur:

CSIDL_COMMON_DOCUMENTS

Modifier: ou utilisez

CSIDL_COMMON_APPDATA

mais définissez les autorisations sur le groupe des utilisateurs authentifiés si possible.

Vous recherchez probablement CSIDL_COMMON_APPDATA. L’IIRC devrait également être un bon choix si vous optez pour une certification du logo Windows. Si cela ne correspond pas à vos exigences, consultez ce lien. sur MSDN , vous devriez pouvoir y trouver la solution la mieux adaptée à vos besoins.
Bonne chance.

Ne pouvez-vous pas simplement utiliser un nom de répertoire fixe, par exemple. c: \ FixedDataForYourProgram

Nous faisons cela sur XP. Je n'ai pas essayé cela par programmation sous Vista / Win7, mais je me suis connecté en tant qu'utilisateur standard sous Vista. Je n'ai aucun problème à créer un répertoire sous root.

Je suis sûr que cela enfreint toutes sortes de règles, mais c'est simple. J'aime les simples.

options:

  1. Mutex de fichier pour contrôler l'accès au fichier
  2. Base de données pour stocker les paramètres
  3. Service Web pour stocker les paramètres permettant de gérer la simultanéité
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top