Fichier invisible dans l’explorateur Windows 7 64 bits

Ce billet est un nouvel épisode dans ma tentative de prise de contrôle de ma nouvelle machine Windows 7 64 bits.

Windows 7 64 bits (mais cela est probablement déjà le cas en Vista 64 bits) possède une notion de VirtualStore qui est susceptible de poser quelques problèmes surprenants. J’en ai détecté deux :

• le fichier que j’ai créé avec un programme 32 bits (en l’occurrence Eclipse) dans un répertoire (en l’occurrence un sous répertoire de ProgramFiles) n’apparait pas quand je passe par l’explorateur.
• depuis une application 32 bits (NS-DK ou NatStar en l’occurrence) les valeurs que je lis dans un fichier (en l’occurrence dans un sous répertoire de ProgramFiles(x86)) ne sont pas celles que je peux lire quand j’ouvre le même fichier par l’explorateur.
• depuis une application 32 bits (la même que précédemment) j’arrive à lire un fichier (en l’occurrence dans un sous répertoire de ProgramFiles(x86)) qui n’est pas visible dans l’explorateur alors que j’affiche les fichiers cachés (c’est en fait un doublon du premier cas)

L’explication de ce phénomène est la création par le système d’un VirtualStore. Le signe visuel que vous avez qu’un VirtualStore qui correspond à votre répertoire a été créé est la présence d’un bouton “Fichiers de compatibilité” dans la barre d’outil de l’explorateur.

Remarquez dans l’exemple ci-dessus, la présence de deux fichiers :

• DemoNatJetCompleted.war le 18/02/2010 à 11:20
• NatJxt3DemoMultiPannel.war le 30/05/2008

On est dans le répertoire “C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps”. Les deux fichiers présents on été copié à la main par l’explorateur. Le processus Tomcat 64 bits détecte correctement ces deux fichiers.

Si on appuie sur le bouton “Fichiers de compatibilité”, on bascule vers le répertoire “C:\Users\jltho.NATSYSTEM\AppData\Local\VirtualStore\Program Files\Apache Software Foundation\Tomcat 6.0\webapps” du VirtualStore.

On a maintenant deux fichiers :

• DemoNatJetCompleted.war du 17/02/2010 à 18:41 : sa date indique qu’il est plus ancien que celui qu’on voyait plus haut.
• NatVie30WF

Ces deux fichiers ont été créé directement depuis un Eclipse 32 bits par la fonction Export/War… Le processus Tomcat ne voit pas ces deux fichiers. Eclipse lui les voit.

Dans le cas de mon application NatStar/NS-DK (il s’agit d’un binaire 32 bits à base de C), le problème était encore plus surprenant : le fichier du VirtualStore a été créé par un autre mécanisme (mon application consulte le fichier exclusivement en lecture). Mon application lisait pourtant ce fichier du VirtualStore. Quand je modifie le fichier dans le répertoire d’origine en passant par l’explorateur, les modifications que je réalise ne sont pas visibles par l’application : elle continue de lire les anciennes valeurs. Si je supprime le fichier dans le répertoire d’origine (ProgramFiles(x86)), l’application continue d’être capable de lire les données alors que depuis l’explorateur je ne vois rien.

Pour info, nous avons détecté le problème grâce à l’utilisation de Process Monitor qui nous a permis de constater que le process ne lisait pas dans le répertoire ProgramFiles(x86) mais dans un autre répertoire.

Une fois dans le VirtualStore (grâce au bouton), vous pouvez surprimer les fichiers. Dans le cas de mon application NatStar/NS-DK, elle s’est mise à lire le bon fichier et ne l’a pas recréé dans le VirtualStore. J’ai modifié ce fichier par l’explorateur depuis, sans que le VirtualStore ne soit recréé.

La règle que l’on peut déduire est la suivante :

• si un process 32 bits écrit dans certains répertoires (a priori ProgramFiles(x86) et ProgramFiles), le système redirige son écriture dans un autre répertoire physique : le VirtualStore
• si une application 32 bits lit un fichier dans un répertoire possédant un VirtualStore, elle lit en premier lieu le fichier s’il existe dans le VirtualStore. Si le fichier n’existe pas dans le VirtualStore et seulement dans ce cas, il va lire le fichier dans le répertoire d’origine.

On constate que pour un processus 32 bits, c’est le fichier dans le VirtualStore qui prévaut.

Pour un processus 64 bits, il ne voit que le répertoire d’origine.

Comment savoir pourquoi un fichier a été virtualisé ?

Cela est possible en utilisant l’Observateur d’événements de Windows 7. Il s’ouvre en tapant dans la zone de commande : Obs puis en sélectionnant ce dernier dans la liste qui apparait.

La rubrique qui nous intéresse est : “Journaux des applications et des services” puis “Microsoft” puis “Windows” puis “UAC-FileVirtualization”. On clique sur le nœud Opérationnel, une liste apparait. Les événements d’ID 4000 indiquent les création de fichiers de virtualisation.

En cliquant sur l’onglet détail, il est possible de savoir qui a créé le fichier concerné :

On voit ainsi qu’un fichier war temporaire a été créé dans le VirtualStore par un process javaw.exe lancé depuis un répertoire C:\NatJet3.0.2\thirdparty\jdk1.5.0_15\bin.

C’est grâce à cela que j’ai compris comment pour mon application NatStar, les fichiers de Virtualisation avaient été créé : il s’agissait de la procédure d’installation de mon application qui lançait un processus 32 bits (switch.exe) pour faire des substitutions dans les fichiers installés dans ProgramFiles(x86).

Conclusion

Ce mécanisme de virtualisation est très surprenant : la volonté de Microsoft semble avoir été d’augmenter la compatibilité des nombreuses applications qui ne respectent pas les droits sur les répertoires ProgramFiles. Cela afin de faciliter la migration lors du passage à Vista : avant Vista les applications avaient les privilèges d’un administrateur, depuis elles tournent avec els droits d’un simple utilisateur : elles n’ont plus le droit d’écrire n’importe où.

Vous trouverez plus d’information sur le sujet dans les deux pages suivantes :

• http://support.microsoft.com/kb/927387 : elle présente d’autres problèmes liés à la virtualisation
• http://windowsteamblog.com/blogs/developers/archive/2009/08/04/user-account-control-data-redirection.aspx : un très bon article en anglais qui explique le fonctionnement de la virtualisation et ses raisons. Il décrit également l’utilisation de Proc Monitor pour détecter les applications qui déclenche la virtualisation.

DiggIt! Enregistrer sur Del.icio.us