Discussion :

[Pierroot]

Bonjour,

Il semblerait que pour Vista, Seven et Windows Server 2008, la gestion du répertoire C:\Program Files (ou Programmes) soit un peu particulière.

Mon problème: J'ai une appli de gestion attaquant une base Access, le tout installé dans C:\Program Files\... sur un PC Seven.

Lorsqu'un autre programme (exécuté sur le même PC par le même User) attaque cette même base Acess, on dirait que chacun d'eux travaille sur une "copie" à lui de la base de données.
De même, s'il on désinstalle, puis qu'on réinstalle au même endroit, c'est la base supprimée qui resurgit !!

NB: Ce problème n'existe pas si l'on fait l'install hors de C:\Program Files... Mais bon, c'est quand même le répertoire où l'on est censé mettre les applis...

Est-ce que quelqu'un a des infos sur cette gestion particulière de Windows ?
Est-ce un problème uniquement Access ?
Qu'en est-il des fichiers autres que .mdb ?
Quelqu'un sait-il comment solutionner ce problème ?

Merci à tous de votre collaboration.

[Louis Griffont]

Le problème vient de la mauvaise utilisation des dossiers ! Une base de données ne doit pas se trouver dans «Program files».

Depuis Vista, Microsoft a restreint l'emploi des dossiers systèmes.

Pour éviter des problèmes, il ne faut pas installer les programmes anciens et/ou mal conçus dans «program files».

[Pierroot]

L'intention est louable, malheureusement, cette réponse n'apporte pas beaucoup d'explication et le conseil d'installer les programmes (difficile de dissocier appli et base) ailleurs que dans le dossier "Programmes" pour éviter les problèmes... Hmm, bon !

Quant à l'emplacement des bases Access, il y a des tutoriaux de Microsoft sur Access et le répertoire utilisé est ... C:\Programmes !!

Bref, je ne suis pas beaucoup plus avancé et toujours pas beaucoup de monde qui semble confronté à ce problème.

Je reste évidemment à l'écoute de toute suggestion !

[nicroman]

Et pourtant...

Ca ne viendrait à personne l'idée d'installer des données modifiables dans /usr/bin sous linux !
Sur windows (depuis 98/2000), c'est pas différent... avec dans l'idée de postes partagés en prime...

Et comme une bonne moitié des programmeurs le faisait "salement" (C:/Program Files ?), depuis Vista, le répertoire "programmes" n'est accessible qu'en "elevated rights". Et histoire de ne pas "casser" 50% des programmes, quand un programme demande à modifier un de ses fichiers, une copie de celui-ci est réalisée dans un répertoire caché du profile local de l'utilisateur. Un peu comme quand on "écrit" sur un CD, ou l'accès aux fichiers .ini qui sont mappés dans la base de registres.


Pour retrouver la position exacte de ces répertoire il faut utiliser SHGetFolderPath, et.. depuis Vista... SHGetKnownFolderPath



Les "fichiers" accessibles à l'administrateur (droits étendus):
FOLDERID_ProgramFiles: Fichiers de l'application sur la machine locale
(FOLDERID_ProgramFilesX64, FOLDERID_ProgramFilesX86)
FOLDERID_ProgramFilesCommon: Fichiers d'application communs entre plusieurs applications sur la machine locale.
(FOLDERID_ProgramFilesCommonX64, FOLDERID_ProgramFilesCommonX86)

Les "données" accessibles en fonction des droits de l'utilisateur:
FOLDERID_ProgramData: Données de l'application sur la machine locale, quelque soit l'utilisateur.
FOLDERID_LocalAppData: Données de l'application pour l'utilisateur courant sur la machine locale (depuis Windows 2000).
FOLDERID_RoamingAppData: Données de l'application pour l'utilisateur courant indépendemment de la machine (depuis Windows 98).

Donc l'idée est simple... un fichier de données modifiée par l'application doit obligatoirement être dans l'un des trois derniers.
Bien entendu, si on veut un fichier partagé par tous les utilisateurs sur toutes les machines... il va falloir passer par un partage réseau !

[Pierroot]

Voilà au moins des informations précises et concrètes...

Reste la question secondaire du "pourquoi" Microsoft a mis en place cette gestion bizarre du répertoire "Programmes" pour laquelle je vois plus d'inconvénients que d'avantages...

Quant au fait de travailler salement en déployant tous les fichiers d'une application (y compris les fichiers de bdd) au même endroit et de surcroît dans le répertoire dédié à cet effet (C:\Program Files...), je ne suis pas d'accord. L'erreur serait plutôt selon moi, d'en mettre un bout par-ci, un bout par là et à tant qu'à faire un peu aussi dans les répertoires systèmes.
C'est précisément ce genre d'installation qui polluent les PCs rendant problématiques les désinstallations (dll partagées par plusieurs applis, etc...).

Mais je rejoins bien volontiers la conclusion: Evitons ce répertoire "C:\Programmes" source d'emm...

Au fait, comment font tous les éditeurs de logiciels qui s'installent (tout à fait logiquement) dans C:\Programmes et qui utilisent des fichiers modifiables pour stocker leurs données (autrement appelés bdd) ?

Sauf questions restantes ci-dessus pour ma culture personnelle, je considère mon problème comme RESOLU.

Merci à tous de vos réponses.

[Jipété]

Salut.

Au fait, comment font tous les éditeurs de logiciels qui s'installent (tout à fait logiquement) dans C:\Programmes et qui utilisent des fichiers modifiables pour stocker leurs données (autrement appelés bdd) ?

Ben ils utilisent "x:\ProgramData", tout simplement : c'est fait pour ça.
("x" parce que c'est pas obligé que le disque système s'appelle "C", ça pourrait être "D" ou +...)

[nicroman]

Salut.


Ben ils utilisent "x:\ProgramData", tout simplement : c'est fait pour ça.
("x" parce que c'est pas obligé que le disque système s'appelle "C", ça pourrait être "D" ou +...)

En fait c'est même FOLDERID_ProgramData
Parceque c'est pas NON PLUS X:\ProgramData... ca pourrait très bien être \\Sotrage\Machine\ProgramData

[nicroman]

Reste la question secondaire du "pourquoi" Microsoft a mis en place cette gestion bizarre du répertoire "Programmes" pour laquelle je vois plus d'inconvénients que d'avantages...

Parceque la base installée de logiciels microsoft est plus que conséquente...
A l'introduction de ces répertoires dans NT5 (Windows 2000) & 98 , microsoft ne pouvait que "suggérer fortement" aux logiciels de les utiliser, considérant la base de programmes "antérieurs".
Dans NT6 (Vista), on passe au niveau supérieur: Interdiction de modifier certains folders... Mais encore une fois, que vaut-il mieux ? Autoriser les programmeurs à utiliser Windows salement (au passage c'est une raison de refus du logo Windows la mauvaise utilisation des répertoires) ? ou bloquer la masse conséquente de logiciels déjà réalisés au risque d'avoir une quantité non négligeables de "mécontents" (au rythme des "Microsoft c'est pourri"...).

Un peu comme dans une API, ou on marque une fonction comme "deprecated": ca veut dire, on sait que certaines personnes l'utilisent, alors on l'enleve pas pour que ca continue à marcher, mais s'il vous plait, ne l'utilisez plus ! Et de toute manière si vous l'utilisez, on fera comme si vous ne l'aviez pas utilisé.

Quant au fait de travailler salement en déployant tous les fichiers d'une application (y compris les fichiers de bdd) au même endroit et de surcroît dans le répertoire dédié à cet effet (C:\Program Files...), je ne suis pas d'accord. L'erreur serait plutôt selon moi, d'en mettre un bout par-ci, un bout par là et à tant qu'à faire un peu aussi dans les répertoires systèmes.
C'est précisément ce genre d'installation qui polluent les PCs rendant problématiques les désinstallations (dll partagées par plusieurs applis, etc...).

Alors là tu confonds tout à mon avis.... DLL et .EXE meme combat ! Tous les systèmes gèrent leur installations pareillement... Si on reprend une installation unix classique, on va avoir des bouts dans ~monuser/.monapp, des bouts dans /usr/var, des bouts dans /usr/bin ... des bouts dans /etc/...
Pour une simple raison, tout n'est pas partagé de la même manière: fichiers "utilisateurs", fichiers "utilisateurs sur la machine locale", fichiers "globaux", fichiers "machine locale"... Et la même chose (ou presque) coté "binaire" (non modifiables avec les droits utilisateurs): code "global", code "machine locale"... Et hop, on retrouve les même folders que chez Minimou...

Il est bien fini le temps du mono-utilisateur mono-poste... Chez moi, quand je lance Outlook du laptop ou de ma grosse machine, j'ai exactement les même settings & fichiers.... Et ils sont (heureusement) différents de ceux ma femme...

Au fait, comment font tous les éditeurs de logiciels qui s'installent (tout à fait logiquement) dans C:\Programmes et qui utilisent des fichiers modifiables pour stocker leurs données (autrement appelés bdd) ?

Ils utilisent un installeur (.msi, ou autre) qui gèrent parfaitement (et de manière quasi transparentes) toutes ces différences....

[shawn12]

J'avais écrit ceci il y a un moment :

Depuis Vista, Windows intègre une nouvelle protection des dossiers et fichiers systèmes (nottament le dossier "Program files" ou "Programmes").

Pour cela le système utilise une sorte de principe de "virtualisation des fichiers".

Aucun utilisateur (compte limité ou admin) ne peut écrire dans les dossiers protégés de windows sans élévation de privilège.

Afin d'éviter les problèmes de compatibilité que cela aurait pu générer, lorsqu'un programme (comme le tien) essaie d'écrire dans un répertoire protégé, Windows 7 ne provoque pas d'erreur et "simule" l'écriture du fichier dans program files/Ton Groupe/Ton programme/. En réalité, comme il est interdit d'y écrire réellement, il les stocke dans un "virtual store" situé dans "C:\Users\nom_utilisateur\AppData\Local\VirtualStore\Program Files\Ton groupe\Ton programme.".
C'est pour cela que chaque utilisateur a un fichier différent.

Tu peux d'ailleur le voir dans l'explorateur windows. Si tu va dans le dossier protégé dans lequel se situe ton fichier cfg, tu verra apparaitre un bouton "fichiers de compatibilité" qui te renverra vers le virtual store.

Essaie d'écrire ton fichier config dans un répertoire partagé accessible à tous les utilisateurs (tu leur donne les droits) et qui ne soit pas protégé par windows

Ce type de protection est important dans un système d'exploitation, le dossier Program Files n'est pas fait pour stocker des paramètres. Il vaut mieux ne pas avoir trop de droits d'écriture sur ce type de dossier (si un virus commence à manipuler des trucs là dedans, ça peut faire de gros dégats.)