How do I get ftype & assoc to match Windows Explorer?

Question

I changed the association to use upon launching a .py file, via Windows Explorer:

1. Tools -> Folders -> File types.
2. Then browse to .py.
3. Change the association to Wordpad.

Now when I type the name of a py file in the command line, Wordpad opens it.

But assoc and ftype in the command line still return the following:

C:\> assoc .py
.py = Python.File

C:\> ftype Python.File
Python.File = "C:\Program\Python27\python.exe" "%1" %*

How come the association is working, but assoc and ftype are not aware of it?

I did restart the prompt.

---

More info from my registry:

HKEY_CLASSES_ROOT\.py
= Python.File

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py\Application
= wordpad.exe

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py\OpenWithProgids\Python.File
= 

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.py\(Standard)
= Python.File

---

More registry:

HKEY_CLASSES_ROOT\Applications\python.exe\shell\open\command\(Standard)
= "C:\Program\Python27\python.exe" "%1" %*`

I suppose this is what is showing up in ftype Python.File. But it does not seem to get used.

---

(I am doing this for testing, so I can eventually choose my default version of Python easily).

Answer 1

Depending on how you call a file will depend on what verb is used. The verb you use determines what Windows will do with it. The standard verbs are Open, Edit, Print, Play, and Preview. However, it is possible to create your own verbs. The most commonly added verb is the Open With family (including OpenWithProgIDs), which add that little context sub-menu under "Open With" to give you possible alternatives. If you install Paint.NET, for example, and then right-click a .jpg file, you'll see the Open With entry expands to a submenu that lists Paint.NET, Paint, and whatever Microsoft called the picture viewer for your version of Windows.

Additionally, what Unsigned Code Labs said is very important. When you're debugging classes, you need to look at HKLM\Software\Classes\ and HKCU\Software\Classes. HKCR is very useful for querying the system, but not so good for finding out why it's misbehaving.

I did a little testing on my Windows 7 system with procmon.exe, and the assoc and ftype commands appear to try to write directly to HKCR, and the system apparently interprets that as writing to HKLM. My current account is a member of the admin group, but UAC is enabled. I got access denied when I tried assoc .mytest=MyTest.File.

Oddly, if I create an association by right-clicking a file called test.mytest and associating it with Notepad, neither assoc nor ftype sees this association. The association is definitely there in HKCU and HKCR. I haven't tried rebooting, however.

Answer 2

i don't know how can you make the match between registry and what appears in ftype and assoc. To me and as i see to you as well the ftype and assoc command are useless. What i do to change the default program for a given extension in a programatic way(vs the standard and more simple way using explorer) is modify this registry key

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

For example, if i want to open my mp3s with mplayer i put in

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

the value of "mplayerc.mp3"

What are the complication of doing this: first you need to know valids ProgIDs(use ftype), and second you need write access to that hive. Windows automatically put a deny ACL for the UserChoice key, so you need to find a way to remove that deny rule in order to get the write access. I use the program subinacl, that you could download from here http://www.microsoft.com/downloads/en/details.aspx?FamilyID=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b&displaylang=en to modify the permissions. Also you could use the 3rd party program SetACL. I recomend the first because the syntax is a lot more simple.

Answer 3

Microsoft have changed how this works from Windows 8 onward. It is no longer possible to edit the registry to change this. To quote Microsoft:

In Pre-Win 8, apps could set the default handler for a file type/protocol by manipulating the registry, this means you could easily have a script or a group policy manipulating the registry. However In Win 8, the registry changes are verified by a hash (unique per user and app) that detects tampering by apps. In the absence of a valid hash, we ignore the default in the registry.

The way Microsoft expect you to change this now is with an xml file which is implemented through Group Policy. Instructions here.

Thankfully Christoph Kolbicz has reverse engineered the hashing algorithm and created a tool called SetUserFTA to set the file type association. Unfortunately it is closed source.

Answer 4

Explorer (the Windows shell) always gives preference to the application specified in the vendor key which is specified under the extension's default value. (In your case .py is the extension, Python.File is the vendor key.)

ftype and assoc may read their values from other areas, I do not know for sure. Thats just how Explorer does it.

EDIT: This page may be of interest to you: MSDN - File Types

Especially this:

The HKEY_CLASSES_ROOT subtree is a view formed by merging HKEY_CURRENT_USER\Software\Classes and HKEY_LOCAL_MACHINE\Software\Classes.

Perhaps this is where the different parts of Windows clash, if there is a "default" association in HKEY_LOCAL_MACHINE, that is getting overridden by the one you defined on your account (which would then be stored in HKEY_CURRENT_USER).

Answer 5

The confusion here is between what is used to open a file and what is used to run a file. The registry key

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

is what tells windows how to open the file. Double clicking on the file will open the file with this application.

As the file isn't an executable file, the command line assumes that you want to open the file with the default application, as if you had double clicked it.

Changing the association back to C:\Program\Python27\python.exe or editing the registry key to point to python should return it to how it used to be, where windows assumes you want to open the file with the default program, which is python.exe, which then runs the program.

Answer 6

Your biggest clue to purpose and location is in the "big type", i.e., the names of the respective hives: HKLM and HKCU

File associations are set in both hives and have two different purposes:

As the name implies, HKCU registry entries set file associations for the CURRENT USER and override the corresponding file type settings in HKLM.

HKLM sets file associations for the LOCAL MACHINE, i.e, for ALL USERS of the machine (unless overridden by HKCU entries). (For Win98, HKCR was just a shorthand alias for HKLM\Software\Classes. They were not separate or different hives. However, this changed for Win XP and is no longer true. HKCR is now a virtual hive that is the result of merging the HKLM\Software\Classes\, HKCU\Software\Classes\, and HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts keys with the HKCU info taking precedence.)

This two step system facilitates not only one-to-one but many-to-one and one-to-many file association schemes. For example, .htm, .html and .shtml filetypes could all be set to ProgID=htmlfile which in turn could define a single browser. OTOH, the entries could contain OpenWithList or OpenWithProgID subkeys with multiple entries to open a file from a list of multiple browsers, editors or other apps.

Both HKLM\Software\Classes\ and HKCU\Software\Classes operate the same way (one just takes precedence over the other). In the simplest form there is a registry key for a file extension (e.g., HKCR.txt) whose default value is the corresponding ProgID (e.g, txtfile). In addition to, or instead of, the default value, there may be additional ProgID names listed for the "OpenWithProgID" subkey (e.g., txtfile and htmlfile), and/or additional application names appearing as subkeys under "OpenWithList" (e.g., Notepad++.exe, Opera.exe, Firefox.exe).

Each ProgID is defined in another key within HKCR (e.g., HKCR\txtfile). This key contains subkeys to tell windows which icon to use and how to open, print, printto, etc the associated file (e.,g, HKCR\txtfile\shell\open\command). Similarly, each application name is defined as a subkey under HKCR\Applications (e.g., HKEY_CLASSES_ROOT\Applications\Firefox.exe\shell\open\command).

In addition to the HKCU\Software\Classes key, user account file associations are found in the HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts key. These entries are not for just Windows Explorer as has been suggested but are an addition source of user account file association overrides. The entries are created by the file association tools in explorer (Explorer \ Tools \ Folder Options \ File Types) and contain an OpenWithList and/or an OpenwithProgID subkey for each listed file extension.

To determine a file association, Windows looks first at the HKCU entries for a corresponding file extension. Only if one is not found do the HKLM entries come into play. (Note: I have not tested which takes precedence - the HKCU\Software\Classes or HKCU\MIcrosoft\Windows\CurrentVersion\Explorer\FileExts but I suspect it would be the FileExts key). Likewise, if a referenced ProgID or application name is not found in HKCU, the HKLM entries are searched. (Note that \Applications\ entries are just arbitrary name - even though they typically are identical to the actual on disk exe file name.)

So to define a file association for a specific user account, create entries in the HKCU hive. To define an association for all users, create entries in the HKLM hive (HKCR) and delete all references in the HKCU hive to that file type. Obviously you need the appropriate access rights to the registry keys.

I don't use the assoc and ftype tools as I prefer using RegEdit in either interactive or batch mode but from other comments it appears that they only operate on the HKLM hive and are useless for clearing/setting HKCU keys. Take some time and browse the abovementioned keys with RegEdit to see more examples.