After updating python to the latest version, an issue related to reading files in long paths (>256 letters) is arisen. Whenever I try to read such a file in Windows 11, I got an exception telling me that the file is not there, even though it’s there and I allowed windows 11 to accept long paths  (> Max_Path). Absolute and relative paths did not work. Projects that were working before normally, are no longer working. The exception is “FileNotFoundError: [Errno 2] No such file or directory: The_Long_Path_To_The_File,

Ensure that the system has LongPathsEnabled set to 1. For example, in PowerShell with administrator (elevated) access:

    PS C:\> $p = "HKLM:\System\CurrentControlSet\Control\Filesystem"
    PS C:\> get-itempropertyvalue $p LongPathsEnabled
    0

It was set to 0, so change it to 1:

    PS C:\> set-itemproperty $p LongPathsEnabled 1
    PS C:\> get-itempropertyvalue $p LongPathsEnabled
    1

Every new process initially checks this registry setting, so you don't have to logoff or reboot for it take effect.

I wonder if the Windows 11 upgrade process disables this registry key when it's set directly?

That's not something we can fix (I don't think?), so we may just have to list it as an option.

If you can, check whether running a Repair of your Python install offers the button at the end to enable it again. If so, that may be the best thing for us to suggest (if this turns out to be widespread).

Oh, no, wait. Did my accidental breakage of the resource files make it into the last 3.9 release? If so, we probably lost the manifest option to opt-in to supporting long paths, and perhaps Windows 11 has decided to start honouring that (Windows 10 ignored it).

(+RM just in case it matters enough to accelerate the next patch release.)

LongPathsEnabled value was already one. This issue comes with the new update (3.9.8) [Windows Store version]. I reinstalled the same version (3.9.8) from Windows Store, and the issue was still there.
When I tried versions (3.10) and (3.9.7) from (https://www.python.org/downloads/), the problem is gone.

> Did my accidental breakage of the resource files make it into the last 3.9 release?

Turns out, no, it didn't. So this is something else.

When I get to work later today I'll take a look.

> Did my accidental breakage of the resource files make it 
> into the last 3.9 release?

Yep, version 3.9.8 of the store app was built last Friday, the day after removing "winuser.h" from the resource definition files. I just installed it and can confirm that there's no embedded manifest in "C:\Program Files\WindowApps\PythonSoftwareFoundation.Python.3.9<...>\python.exe".

> I just installed it and can confirm that there's no embedded manifest in "C:\Program Files\WindowApps\PythonSoftwareFoundation.Python.3.9<...>\python.exe".

Strange, because when I inspect the files that I published, it's there. 
It's also in the version that I installed on another machine from the Store.

How are you checking whether it's there or not?

> How are you checking whether it's there or not?

The desktop distribution of 3.9.8 is the most obvious case, since it causes sys.getwindowsversion() to report Windows 8.0 (6.2.9200):

    C:\Temp>"C:\Program Files\Python39\python.exe" -q
    >>> import sys
    >>> sys.getwindowsversion()
    sys.getwindowsversion(major=6, minor=2, build=9200, platform=2, service_pack='')

But I checked for the manifest directly using the SDK manifest tool, mt.exe. It's missing in 3.9.8:

    C:\Temp>set file=C:\Program Files\Python39\python.exe
    C:\Temp>mt -nologo -inputresource:"%file%";#1 -out:python.manifest
    mt : general error c101008c: Failed to read the manifest from the resource of file 
    "C:\Program Files\Python39\python.exe".
    The specified resource type cannot be found in the image file.

    C:\Temp>set file=C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.2288.0_x64__qbz5n2kfra8p0\python.exe
    C:\Temp>mt -nologo -inputresource:"%file%";#1 -out:python.manifest
    mt : general error c101008c: Failed to read the manifest from the resource of file
    "C:\Program Files\WindowsApps
       \PythonSoftwareFoundation.Python.3.9_3.9.2288.0_x64__qbz5n2kfra8p0
       \python.exe". 
    The specified resource type cannot be found in the image file.

For comparison, the manifest is present in 3.10, which was built over a month ago:

    C:\Temp>set file=C:\Program Files\Python310\python.exe
    C:\Temp>mt -nologo -inputresource:"%file%";#1 -out:python.manifest
    C:\Temp>findstr longPathAware python.manifest
          <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>

    C:\Temp>set file=C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.10_3.10.240.0_x64__qbz5n2kfra8p0\python.exe
    C:\Temp>mt -nologo -inputresource:"%file%";#1 -out:python.manifest
    C:\Temp>findstr longPathAware python.manifest
          <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>

Oh I think I know what happened. Because RT_MANIFEST wasn't defined, it was added as a resource tagged with that as a string. So the manifest is still embedded, just not under the right type constant, so it has no effect.

Yeah, I think we should do a fresh release. Perhaps combined with the recent Tk updates for macOS we'll have more releases soon anyway?

Marking this as fixed, because the fix is already checked in. Release scheduling is a separate conversation, so keep an eye out for the next release.