Avec Windows Vista, les accès aux fichiers/dossiers ont été repensés, afin de mieux séparer les divers types d'utilisateurs.
Il s'agit de l'UAC, pour "User Account Control".
Par exemple, lorsqu'un utilisateur sans droits d'administration essaie de toucher à un fichier du système, le mot de passe administrateur lui est demandé.
Lorsqu'on installe un logiciel, des confirmations diverses viennent émailler le processus.
Ainsi, si quelque chose se passe mal, vous ne pouvez plus vous en prendre qu'à vous-même, car vous n'auriez pas du valider sans réfléchir la 4e boîte d'alerte qui est apparue. Eh oui, au bout d'un moment, on le lit plus toutes ces boîtes et on clique machinalement, pressés d'arriver au bout de la procédure. Mais c'est votre faute, yavékapa.
Par exemple, l'accès en écriture au dossier "Program Files", où s'installent tous les programmes, est ainsi réservé à l'administrateur, un utilisateur "normal" n'ayant pas les droits d'accès en écriture sur ce répertoire.
Jusque-là, tout pourrait bien aller, mais c'est ici qu'il faut suivre le raisonnement :
les gars de chez Microsoft se sont aperçus que certaines applications écrivaient des fichiers (configuration, etc) dans ce dossier, lors d'une utilisation normale. Ces applications ne fonctionnaient donc pas correctement sur Vista. De plus, ces fichiers écrits par un utilisateur étaient également valables pour un autre, tout le monde se partageant donc les mêmes fichiers.
Une idée de génie a alors fusé : fournir à chaque utilisateur sa propre version des fichiers présents dans ce dossier. Lorsqu'un utilisateur modifie un des fichiers, le système pourrait en créer une copie, et fournir à l'utilisateur cette copie plutôt que le fichier original.
C'est lors de la mise en place de cette fonctionnalité que le bât a blessé. Deux choses ont été oubliées :
1- Qu'un programme, et tous ses fichiers, pouvait être désinstallé
2- Que l'utilisateur, lorsqu'il explore le dossier "à la main", souhaiterait voir la version du fichier que voient les applications, et non le fichier original.
Prenons un exemple. Votre application préférée modifie un fichier "config.txt" dans un sous-répertoire de son dossier d'installation
C:\Program Files\ApplicationPréférée
Le système crée une copie de config.txt et la stocke dans le dossier caché
C:\Documents And Settings\<utilisateur>\Local Settings\Application Data\VirtualStore\Program Files\ApplicationPréférée
(un chemin d'accès aussi simple, c'est fait pour faciliter les choses).
A partir de maintenant, lorsque vous utiliserez l'application, lorsqu'elle essaiera de lire le fichier "config.txt" dans "C:\Program Files", le système lui fera lire cette copie, de manière totalement transparente.
Maintenant, imaginons que quelque chose fonctionne mal, parce que vous avez voulu modifier des paramètres dans l'application et que vous vous y êtes mal pris. Vous savez que l'application stocke son fichier de configuration dans "Program Files". Vous ouvrez ce fichier à la main, et, surprise, vous voyez le contenu original, et pas ce que vous avez modifié.
Qu'à cela ne tienne. Vous désinstallez l'application, effacez tout le contenu du dossier, nettoyez la base de registre, et réinstallez. Lorsque vous lancez l'application, vos paramètres sont toujours là. Impossible de les supprimer, à moins de connaître le principe de l'UAC sur Vista, et le chemin d'accès sur VirtualStore.
Nous avons eu quelques soucis (le mot est faible) avec ceci. Par exemple, le fichier crash.log est complété à chaque fois qu'un nouveau crash survient. Sur Vista, il va se loger dans le dossier VirtualStore de l'utilisateur. Comment expliquer raisonnablement à un utilsateur lambda qu'il doit demander d'afficher les dossiers cachés, et se balader au fin fond des répertoires Documents And Settings pour trouver la bonne copie ?
Nous avons modifié l'application MyrPref, présente dans le dossier d'installation de Melody ou Harmony pour ouvrir automatiquement ce répertoire lorsque la touche Ctrl est appuyée lors du double-click. Si vous êtes sous Vista, essayez-le. Vous verrez ainsi toutes les copies personnelles des fichiers des diverses applications qui écrivent dans le répertoire "Program Files" (y compris celles qui ont été désinstallées depuis belle lurette). Ca peut être utile à savoir, si un jour vous avez un problème...
Et vous pourrez vous consoler en vous disant que vous n'êtes pas le seul dans ce cas, comme le prouve cette recherche Google. |
