Recognize Windows executable and script by file extension

[qqkookie]

Problem

Linux does not recognize Windows executable and script files ( and its extension) on mounted Windows filesystem without --x--x--x file mode bits.
But WSL doe not set execute bit automatically only for Windows executable and script files.
So if user set fmask=000 for automount option, then all Windows files are regarded as executable, regardless it is really Windows executable or plain data (mode = -rwxrwrwx), which I don't want.
And if fmask is set to 111 (fmask=111), then all window executables (.exe) files are regarded as non-executable data and if I try to run write.exe, then bash issues permission denied. error and refuse to run it. User have to set the execute bit manually to run it. Here is my wsl.conf

# /etc/wsl.conf 
[automount]
enabled	= true 
options	= "metadata,umask=022,fmask=111"
[interop]
enabled	= true

Solution

Implement something similar to %PATHEXT% Windows environment variable so that WSL will recognize Windows exe files extension and set default execute bit by extension. For example, if [interop] section of /etc/wsl.conf have "executables" attribute that lists extensions of Windows executable files. For example, executables="exe sh py", then all files with .exe or .sh or .py file extension on mounted Windows file system will have default execute bit set (rwxrwxrwx) and masked by fmask bits. All other files with extensions not listed in the attribute will have default execute bit unset (rw-rw-rw)

So If user sets fmask=011, then write.exe file have rwxr--r-- permission mode bits. and all other data files (like data.txt with non-executable extension ) will have rw-r--r-- permission mode. User can set execute bit manually (regardless of file extension) by chmod +x file.script .

Alternate Solution

Windows file meta data or ACL(access control list) may have execute permission bit for any (and all) WSL user. But it may be bit too much.

[therealkenc]

Windows executable or plain data (mode = -rwxrwrwx), which I don't want.

This is a variation #2515 (message), ref rambling discussion #3165 (message), and #2421 (probably motivation behind #3267 too). Sometimes also known as "I don't like the green in ls".

Those files do have the executable bit set, and this is reflected in the mode bits in ntfs-3g, samba shares, et al since... always. Unix mv(1)/ rename(2) is not semantically related to chmod(1)/chmod(2). [Analogy: consider the same ask for ntfs-3g, and wonder how far it would fly.]

Possible alternatives to this ask being entertained would be:

(1) Crazy FUSE passthrough filesystem (similar bindfs) that actually had "rename means chmod" semantics. This would work with any filesystem, nevermind 9p. [No one would do this, which is why it doesn't already exist.]
(2) More reasonable: Expand GNU ls(1) + .dircolors to be even more clever, or invent a power-liststuff. [This might actually exist, idk.]

[kurazsi]

The bigger issue, with this fact is that if someone has a git repository and the content of that git repo is modified by windows IDE, then the files that are touched (edited, saved and then undo-ed and saved) show up in git as changed, because there attributes are changed...