Discussion :

[titchagui]

Bonjour,

Je voudrais savoir s'il y avait des recommandations concernant la sauvegarde de certaines données d'une application?
Je m'explique, j'ai une application pour laquelle j'aimerai sauvegarder certaines préférences et je voudrai le faire dans un fichier. Ces préférences peuvent être de différents types, par exemple : dernier fichier utilisé, log d'actions, ...

Supposons que j'ai une application "monappli", la première idée qui m'est venu était d'enregistrer un fichier de préférence "mypref.xml" dans le répertoire :
#sous windows
"%USERPROFILE%/.monappli"
#sous unix
"$HOME/.monappli"

Le répertoire .monappli me permettant ainsi de regrouper d'autres fichiers.

Serait-ce la bonne méthode?
J'ai constaté que certaines applications mettaient certains de leurs fichiers dans "%USERPROFILE%/Application Data/monappli" où mon appli est un nom d'application quelconque (par exemple Mozilla).
Je me dis que je pourrais aussi le faire mais une autre question se pose : Le répertoire "Application Data" s'appelle t'il toujours ainsi? Selon la langue, est-ce que ça ne va se changer en "Données d'application" (pour le fr) par exemple?
Dans ce cas existe t'il une variable d'environnement définissant le nom de "Application Data"?
J'ai vu qu'il y avait une variable d'environnement %APPDATA%. Est t'elle forcément définie?
Sous Vista, ces variables restent t'elles les mêmes?
Sous Windows, je pourrais aussi mettre mes données d'application dans %ALLUSERSPROFILE% mais sous Unix?
Sous Unix, on a la variable $HOME pour le compte utilisateur mais existe t'il une variable permettant de définir des données globales à tous les utilisateurs?

Autre truc, j'ai un fichier de licence pour cette application. Où serait t'il le plus simple de le copier? dans le répertoire %USERPROFILE%/.monappli (et $HOME/.monappli) ? Je sais que le plus simple serait le répertoire où est déployé mon application mais là ce qui m'embête c'est Unix! On doit faire face à des sociétés qui gèrent de façon très stricte les droits sur les répertoires. Du coup c'est souvent un administrateur système qui s'occupe de faire les installs et quand un utilisateur lambda veut utiliser une application, il ne pourra pas les droits pour modifier le repertoire de l'application du coup enregistrer automatiquement un fichier dans le répertoire de l'appli me semble pas la bonne solution.

Tous vos conseils, avis sur la question seront les bienvenus

[Alp]

La façon de faire des applications "sérieuses" c'est bien celle qui consiste à mettre dans Application Data sous win, dans ~/.ton_appli sous linux.

La license tu peux aussi la mettre là.

Qu'est-ce qui te gêne dans cette perspective ?

[loufoque]

Y'a pas une variable d'environnement APPDATA ?
À part ça, pas de grand rapport avec le C++.

[ram-0000]

Un autre choix mais qui ne concerne que l'environnement Microsoft, c'est la base de registres

HKEY_LOCAL_MACHINE pour tout ce qui est global
et HKEY_CURRENT_USER pour les données spécifiques utilisateur

[titchagui]

La façon de faire des applications "sérieuses" c'est bien celle qui consiste à mettre dans Application Data sous win, dans ~/.ton_appli sous linux.

Sous linux, supposons que l'admin installe l'application dans le répertoire /opt/monappli (accessible par tous). Soit un utilisateur User1, il va lancer l'appli et elle va lui demander un fichier de licence. L'appli va copier automatiquement cette licence dans le répertoire ~/.monappli. OK ça marchera toujours pour User1. Si un utilisateur User2 lance l'appli, celle-ci va chercher dans ~/.monappli pour voir si la licence y est or elle n'y sera pas puisqu'elle est dans le $HOME de User1. L'appli va lui redemander la licence mais, justement, c'est ce que je voudrais éviter. Tu vois mon souci?

Y'a pas une variable d'environnement APPDATA ?
À part ça, pas de grand rapport avec le C++.

Pour APPDATA, je sais qu'elle existe (j'en ai parlé dans mon post) mais la question c'était est t'elle toujours définie? Bon j'ai eu ma réponse, elle est toujours définie au niveau Windows (de la même façon que USERPROFILE)

À part ça, pas de grand rapport avec le C++.

Désolé je ne l'ai pas précisé mais je suis dans un contexte C++. Du coup, je voulais savoir s'il existait une méthode C++ qui permette de récupérer un répertoire accessible pour ajouter des données d'application, une sorte de getSystemAppData() ou un truc dans le genre comme ça ça serait encore plus simple, ça serait standard et je serai bien content .

HKEY_LOCAL_MACHINE pour tout ce qui est global
et HKEY_CURRENT_USER pour les données spécifiques utilisateur

Effectivement, mais malheureusement on veut éviter d'aller fouiller dans la base de registres. Si ça tenait qu'à moi, je le ferai mais bon...

[Médinoc]

Pour obtenir le chemin de Application Data sous Windows, on est supposé utiliser la fonction SHGetFolderPath().

Ou bien, pour des paramètres de configuration, les mettre dans HKEY_CURRENT_USER\Software\titchagui\MonApplication

[unmanos]

Sous windows, si on separe en 3 les types fichiers necessaires:

A. les fichiers statiques d'application commun (en general "program files").

B. CSIDL_COMMON_APPDATA / les fichiers temporaires d'application (par example un systeme d'auto update qui doit telecharger un patch, car impossible de creer un fichier dans "program files" sans les droits superuser).

C. CSIDL_LOCAL_APPDATA / les fichiers de config pour chaque utilisateurs.
Plutot que d'utiliser la registry, pourquoi ne pas mettre un fichier de config xml la dedans?

Sachant que pour modifier B et C tu n'a pas besoin d'avoir de droits super user (elevated pour Vista). Pour modifier A, tu dois relancer ton application avec ShellExecuteEx et le verb a "run as". Et moi qui pensait qu'il allait simplifier leur systeme avec Vista...

[nicroman]

La registry n'est à utiliser que pour de *très* rares cas... Il est bien dommage que les programmeurs n'aient pas suivi les recommendations de M$ parceque cette registry est devenu un sacré b...l

A noter que le HKCU n'est pas toujours disponible (services)... ni le %USERPROFILE%


Sous linux, il ya /etc pour tout ce qui est config "globale", et ~/.xxxx pour les config "user"...
Sous Windows, c'est plus compliqué... et tous les chemins sont configurables... (My Documents par exemple ne pointe pas dans %USERPROFILE% chez moi, et je ne parle pas de My Images qui va sur un répertoire commun à tout le domaine).

[unmanos]

La registry n'est à utiliser que pour de *très* rares cas... Il est bien dommage que les programmeurs n'aient pas suivi les recommendations de M$ parceque cette registry est devenu un sacré b...l

Entierement d'accord... mais a mon avis c'est parce que justement c'est le seul endroit ou tu sais que tu peux aller taper dedans de maniere relativement simple sans droits superuser.

Si MS avait eu des le depart un systeme cler, ca ne serait pas autant le b....l ^^ Dans le genre poubelle, que dire aussi des repertoires temps que tout le monde utilise pour tout et n'importe quoi...

[Médinoc]

La registry est très bien organisée quand on s'en sert correctement...
Bien sûr, il y a toujours des gens qui se gourent, et qui par exemple, consultent une clé non-documentée de Windows au lieu d'utiliser SHGetFolderPath()...

Le registre EST censé remplacer les vieux fichiers .ini, avec les paramètres globaux d'une application dans HKLM\Software\Editeur\Application et les paramètres utilisateur dans HKCU\Software\Editeur\Application...

(évitons de parler de HKCR, qui lui aussi suit des règles spécifiques, seulement ce ne sont pas les mêmes)

Et bien sûr, une de ses principales fonctions est aussi de pallier au fait que les programmes d'installation laissent à l'utilisateur le choix de l'endroit où il veut placer le programme qu'il installe...

[unmanos]

La registry est très bien organisée quand on s'en sert correctement...

C'est a dire pas grand monde... Juste pour rigoler, je viens d'exporter ma registry en texte pour voir le nombre de clefs, resultat apres une install XP qui date de 2 ans (et sur ma machine je n'ai que mes applis pro, j'utilise une VM Ware ou mon notebook pour faire joujou)... 226 Mega octets de clefs??

La plupart des programmes (y conpris ceux estampiller XP Compatible ou Vista Ready machin) laissent des centaines de clefs dans la registry meme apres une desinstallation. Question organisation on a vu mieux. Franchement en 2007, pour remplacer un ".ini" on fait un xml ou autre qu'on met dans CSIDL_COMMON_APPDATA pour les settings globaux et dans CSIDL_LOCAL_APPDATA pour les settings user (en utilisant SHGetFolderPath bien sur). La seule utilisation que j'ai de la registry c'est pour que mon programme apparaissent dans la liste de programme a desinstaller.

Je suis plutot pro microsoft (il faut que ca arrive), mais si il y a bien une mauvaise reponse a un vrai probleme, c'est bien le design meme de la registry.

[Médinoc]

Le problème de désinstallation est un vrai problème, ça je suis prêt à le reconnaître (notamment pour les paramètres utilisateur d'un programme). D'un autre côté, le même problème se présente avec le CSIDL_APPDATA de chaque utilisateur...

Mais le registre reste nécessaire: Un programme d'autorun d'un CD de jeu par exemple, ne peut pas savoir si le jeu est déjà installé sans consulter le registre, puisque l'utilisateur peut avoir installé le jeu n'importe où sur le disque...

[Invité]

Médinoc a raison dans la mesure où Win32 fournit en général des fonctions pour récupérer les infos plutôt que de forcer le développeur à aller lire manuellement le registre. Lorsqu'elles existent, il faut les utiliser.

Il y a tout de même certains avantages à ne pas utiliser le registre pour stocker des paramètres d'applications. Le plus important, je pense, est que les fichiers texte sont plus simples à manipuler pour un humain. Le registre offre une structure intéressante, mais enferme le développeur dans un format qu'il ne maîtrise pas. Pour une petite appli, je n'y vois pas d'inconvénient, mais pour un projet plus ambitieux, je choisirais un format texte simple (du XML léger, ou du moins quelque chose de lisible et structuré).

Bon courage,

Carl

[titchagui]

Merci pour les réponses.
Je suis aussi pour mettre les infos dans un tit fichier XML.
Je retiens le coup du SHGetFolderPath (). J'étais sur qu'une fonction de ce style existait pour Windows.
Dommage qu'il y ait pas une fonction du même style pour Unix...
Je vais voir ce que je vais faire avec le /etc