Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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).

share|improve this question

5 Answers 5

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.

share|improve this answer

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.

share|improve this answer

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).

share|improve this answer

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.

share|improve this answer
    
If I understand correctly, the key .py\Application is used to open the py files. What I do not understand is in what cases the value in Python.File is used. –  Gauthier Mar 2 '11 at 12:40
    
According to Majenko it depends on weather given extension is treated by Windows like executable (see PATHEXT variable). However I recall reading in the past that associates made from within Explorer always overwrite those from Classes registry key. –  Piotr Dobrogost Oct 28 '12 at 15:18

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). (BTW, HKCR is just an shorthand alias for HKLM\Software\Classes. They are not separate or different hives).

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.

Both HKLM\Software\Classes\ (HKCR) 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 HKCR 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 HKCR 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.

share|improve this answer
    
HKCR does not work the way you think it does. In HKCR, I have a "sourcecode" entry. "sourcecode" does not exist in HKLM\Software\Classes. On the other hand, in HKCU\Software\Classes, "sourcecode" is present. So, obviously HKCR includes entries from HKCU\Software\Classes. On the other hand, in both HKCR and HKLM "SoundRec" and "SPCFile" are present. But HKCU\Software\Classes does not have these. Thus, HKCR also obviously includes entries from HKLM. HKCR is definitely merging the two locations in some fashion. Also see superuser.com/a/266274 –  Ben Oct 14 at 18:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.