Comment faire correspondre ftype et assoc à l'explorateur Windows ?

Le verbe utilisé dépend de la manière dont vous appelez un fichier. Le verbe que vous utilisez détermine ce que Windows fera avec le fichier. Les verbes standard sont Ouvrir, Modifier, Imprimer, Lire et Prévisualiser. Cependant, il est possible de créer ses propres verbes . Le verbe le plus souvent ajouté est le Ouvert à la famille (y compris OpenWithProgIDs), qui ajoutent ce petit sous-menu contextuel sous "Ouvrir avec" pour vous donner des alternatives possibles. Si vous installez Paint.NET, par exemple, et que vous cliquez avec le bouton droit de la souris sur un fichier .jpg, vous verrez que l'entrée "Ouvrir avec" se transforme en un sous-menu qui répertorie Paint.NET, Paint et tout ce que Microsoft a appelé le visualiseur d'images pour votre version de Windows.

En outre, ce qu'a dit Unsigned Code Labs est très important. Lorsque vous déboguez des classes, vous devez examiner les éléments suivants HKLM\Software\Classes\ y HKCU\Software\Classes . HKCR est très utile pour interroger le système, mais pas vraiment pour savoir pourquoi il se comporte mal.

J'ai fait un petit test sur mon système Windows 7 avec procmon.exe et le assoc y ftype Les commandes semblent essayer d'écrire directement dans HKCR et le système interprète apparemment cela comme une écriture dans HKLM . Mon compte actuel est membre du groupe des administrateurs, mais l'UAC est activé. J'ai obtenu un refus d'accès lorsque j'ai essayé assoc .mytest=MyTest.File .

Curieusement, si je crée une association en cliquant avec le bouton droit de la souris sur un fichier appelé test.mytest et en l'associant au Bloc-notes, ni assoc ni ftype voit cette association. L'association est bel et bien présente dans HKCU y HKCR . Je n'ai cependant pas essayé de redémarrer.

Je ne sais pas comment vous pouvez faire la correspondance entre le registre et ce qui apparaît dans ftype et assoc. Pour moi et comme je le vois pour vous aussi, les commandes ftype et assoc sont inutiles. Ce que je fais pour changer le programme par défaut pour une extension donnée d'une manière programmatique (par rapport à la manière standard et plus simple en utilisant l'explorateur) est de modifier cette clé de registre

HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.TheExtensionYouWantToModify\UserChoice\ProgID

Par exemple, si je veux ouvrir mes mp3 avec mplayer, je mets

HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.mp3\UserChoice\ProgID 

la valeur de "mplayerc.mp3"

Quelles sont les complications de cette opération : premièrement, vous devez connaître les valides ProgIDs (utiliser ftype), et deuxièmement, vous devez avoir un accès en écriture à ce répertoire de stockage. Windows met automatiquement une ACL de refus pour la clé UserChoice, vous devez donc trouver un moyen de supprimer cette règle de refus afin d'obtenir l'accès en écriture. J'utilise le programme subinacl, que vous pouvez télécharger ici http://www.microsoft.com/downloads/en/details.aspx?FamilyID=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b&displaylang=en pour modifier les autorisations. Vous pouvez également utiliser le programme tiers SetACL. Je recommande le premier car la syntaxe est beaucoup plus simple.

Microsoft a modifié ce fonctionnement à partir de Windows 8. Il n'est plus possible de modifier le registre pour changer cela. Pour citation Microsoft :

Avant Win 8, les applications pouvaient définir le gestionnaire par défaut d'un fichier type de fichier/protocole en manipulant le registre. Cela signifie que vous pouvez facilement avoir un script ou une politique de groupe manipulant le registre. Cependant, dans Win 8, les modifications du registre sont vérifiées par un hachage (unique par utilisateur et par groupe). par utilisateur et par application) qui détecte les manipulations par les applications. En l'absence d'un d'un hachage valide, nous ignorons la valeur par défaut du registre.

La façon dont Microsoft souhaite que vous changiez cela maintenant est un fichier xml qui est mis en œuvre par le biais de la stratégie de groupe. Instructions aquí .

Heureusement, Christoph Kolbicz a inversé l'algorithme de hachage et créé un outil appelé SetUserFTA pour définir l'association du type de fichier. Malheureusement, il s'agit d'un logiciel fermé.

Explorer (le Shell de Windows) donne toujours la préférence à l'application spécifiée dans la clé du fournisseur qui est spécifiée sous la valeur par défaut de l'extension. (Dans votre cas .py est l'extension, Python.File est la clé du fournisseur).

ftype y assoc peuvent lire leurs valeurs dans d'autres domaines, je n'en suis pas certain. C'est simplement la façon dont Explorer procède.

EDITAR: Cette page peut vous intéresser : MSDN - Types de fichiers

En particulier ceci :

La sous-arborescence HKEY_CLASSES_ROOT est une vue formée par fusion HKEY_CURRENT_USER \Software\Classes et HKEY_LOCAL_MACHINE \Software\Classes.

C'est peut-être là que les différentes parties de Windows s'opposent, s'il existe une association "par défaut" dans HKEY_LOCAL_MACHINE, qui est remplacée par celle que vous avez définie pour votre compte (qui serait alors stockée dans HKEY_CURRENT_USER).

La confusion est ici entre ce qui est utilisé pour ouvert un fichier et ce qui est utilisé pour courir un dossier. La clé de registre

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py\Application
\.py\Application

indique à Windows comment ouvrir le fichier. Un double clic sur le fichier l'ouvrira avec cette application.

Comme le fichier n'est pas un fichier exécutable, la ligne de commande suppose que vous souhaitez ouvrir le fichier avec l'application par défaut, comme si vous aviez double-cliqué dessus.

Changer l'association en C:\Program\Python27\python.exe ou la modification de la clé de registre pour qu'elle pointe vers Python devrait permettre de revenir à la situation antérieure, où Windows suppose que vous souhaitez ouvrir le fichier avec le programme par défaut, à savoir Python.exe, qui exécute alors le programme.