This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: os.stat(filepath).st_mode gives wrong 'executable permission' result
Type: behavior Stage: needs patch
Components: Extension Modules, Windows Versions: Python 3.1, Python 3.2, Python 3.3, Python 2.7
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: brian.curtin, georg.brandl, jeroen.dobbelaere, loewis, sijinjoseph, tim.golden
Priority: normal Keywords: easy

Created on 2011-01-11 13:12 by jeroen.dobbelaere, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (10)
msg126004 - (view) Author: Jeroen Dobbelaere (jeroen.dobbelaere) Date: 2011-01-11 13:12
The 'os.stat' method on windows seems to be hardcoded to check the file name extension when computing the 'executable permission flag' (st_mode).

(See Modules/posixmodule.c:  win32_stat and win32_wstat)

Currently, it checks for : 
 '.bat', '.cmd', '.exe', '.com'

As dynamic libraries also must be executable on window, t should also check for : 

It would be even better if the actual 'read and execute' permission is returned.
msg126018 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2011-01-11 16:05
The "Read & Execute" permission listed on a file's property window doesn't really mean anything. Executables only need read permissions [0] to actually be executed.

Additionally, in terms of _stat, Windows does its check by extension [1] but they don't specify what extensions they look for.

Adding ".dll" checking would be the most we could do here.

[1] See "st_mode" halfway down the page,
msg126025 - (view) Author: Jeroen Dobbelaere (jeroen.dobbelaere) Date: 2011-01-11 18:12
Some more background:
The actual issue was initially detected when observing that the 'tarfile' package produced a tar containing different permissions, depending on the script being executed by 'cygwin python' or 'native python'.

When using native python to do the 'untar', I did not observe any issue (as it seems to automatically add 'read and execute' for all files).
But, when I used 'cygwin tar', the .dll did not get its 'read and execute' permission (as it was not specified in the tar file), which then resulted in program that crashed (with a very unhelpful message). Allowing 'read and execute' manually resolved the crash.

So, although this permission should not mean anything, it does seem to have some influence :(
msg126028 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2011-01-11 18:25
> The actual issue was initially detected when observing that the
> 'tarfile' package produced a tar containing different permissions,
> depending on the script being executed by 'cygwin python' or 'native python'.

I would expect that. Each of those work in their own world when it comes to file permissions, and there really isn't a 1-to-1 match when it comes to working in both environments.

On native Windows, "Read & Execute" has no real affect on applications, as it appears to be a synthetic permission probably constructed for that property window. I just looked at a number of definitely not executable files on my computer (e.g., text files), and they are all listed as "Read & Execute". Even by right clicking and adding a new file with a garbage name, no extension, and no contents, it's still "Read & Execute" enabled.

Additionally, there is no programmatic way to set that "Read & Execute" flag that you see in the property window.
msg126047 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-01-11 23:01
Brian: "On native Windows, "Read & Execute" has no real affect on applications". Why do you say that? The FILE_EXECUTE permission certainly has a meaning on Windows, see

I agree that FILE_EXECUTE is, in principle, mostly the equivalent of the x bit on POSIX. Unfortunately, it's also confusing, since most files have that permission.
msg126052 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2011-01-11 23:48
I meant that it doesn't have any effect because it's apparently always set from what I could see, which was poor wording. The TechNet article also made a similar claim. If it is ever not set, then the file clearly can't be executed.
msg133992 - (view) Author: Sijin Joseph (sijinjoseph) Date: 2011-04-18 21:26
From reading it does look like the .dll extension needs to have the "Read & Execute" permission in order to have code from the .dll be executed. It's odd that there isn't documentation that's easily searchable to confirm this.

Also what about scripts, .vbs, .ps1 etc. Should those be considered executables as well?
msg133993 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-04-18 21:42
Jeroen: I'm tempted to close this issue with no change. The code, as it stands, models what Microsoft does in it's CRT (see crt/src/stat.c:__tdtoxmode). There is also a straight-forward motivation to this: this is the list of extensions that you can pass to system() and friends (i.e. ultimately to CreateProcess, if cmd.exe can get involved).
msg134026 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2011-04-19 09:26
FWIW I agree with MvL: os.stat is one of those awkward customers
left over from the idea that Windows could be posix-compliant,
even though the relevant concepts don't actually map particularly
well. ISTM that anyone seriously wanting to determine whether
something's executable or not on Windows is going to have in
mind the precise semantics of a particular use-case and will
employ whatever API calls meet that need. I genuinely don't
believe there's any mileage in shoehorning more and more
corner-cases into os.stat on Windows.
msg199755 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2013-10-13 18:31
Closing as suggested.
Date User Action Args
2022-04-11 14:57:11adminsetgithub: 55097
2013-10-13 18:31:24georg.brandlsetstatus: pending -> closed

nosy: + georg.brandl
messages: + msg199755

resolution: wont fix
2012-10-20 16:32:49serhiy.storchakasetstatus: open -> pending
2011-04-19 09:26:34tim.goldensetnosy: + tim.golden
messages: + msg134026
2011-04-18 21:42:30loewissetmessages: + msg133993
2011-04-18 21:26:19sijinjosephsetnosy: + sijinjoseph
messages: + msg133992
2011-01-11 23:48:34brian.curtinsetmessages: + msg126052
2011-01-11 23:01:00loewissetnosy: + loewis
messages: + msg126047
2011-01-11 18:25:20brian.curtinsetmessages: + msg126028
2011-01-11 18:12:58jeroen.dobbelaeresetmessages: + msg126025
2011-01-11 16:05:51brian.curtinsetcomponents: + Extension Modules
versions: + Python 3.1, Python 3.2, Python 3.3
keywords: + easy
nosy: + brian.curtin

messages: + msg126018
stage: needs patch
2011-01-11 13:12:58jeroen.dobbelaerecreate