#1304 Failed to open file with long filepath even with MAX_PATH disabled

[Tomas Berger]

When running makensis Installer.nsi on my installer I am running into a MAX_PATH length problem it seems.
When it runs the line
File /r "..\Name-Of-App\*"
I get an error:
File: failed opening file "..\Name-Of-App\long\path\name"
When checking what the absolute path becomes, it ends up at 262 characters.
Now I have enabled long path on Windows, so that should not be the problem.
I moved the source code and everything related somewhere with a shorter path, and it builds correctly.

At this point I assume it's either a bug or a missing feature inside nsis

[jp]

Since this is known for 10 years and a fix was deemed unnecessary, one has to assume it is an intended limitation of NSIS.

[Tomas Berger]

Thank you for the response, I hope it can one day be included.
I never saw this Pull/Patch request, so than you so kuch for that. I at least have the possibility to compile my own NSIS. So I will probably do that with that patch (if it still works). I hope one day it can be incorporated to the main release

[jp]

No worries. Let me know if you are successful in self-compilation. I have not had the time yet to try and would still be interested such that we can finally use deeper directory hierarchies.
If you are, we should make a case for the importance of finishing that PR. Apparently it needs some cleanup/corner cases.

[Anders]

It MIGHT be possible to add a makensis.exe.manifest file to NSIS\Bin that unlocks long path support (the policy/registry entry also needs to be set). This has never been tested and might crash or not work.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"><assemblyIdentity version="1.0.0.0" processorArchitecture="*" name="Nullsoft.NSIS.makensis" type="win32"/>
    <description>makensis</description>
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"><security><requestedPrivileges><requestedExecutionLevel level="asInvoker" uiAccess="false"/></requestedPrivileges></security></trustInfo>
    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"><application><supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/><supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/><supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/><supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/></application></compatibility>
<application xmlns="urn:schemas-microsoft-com:asm.v3"><windowsSettings><longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware></windowsSettings></application>
</assembly>

[jp]

I am not sure if a software automagically becomes long file path aware by just specifying it in the manifest (which needs to be done in VS and should be done in your build system, not on a users machine).
You probably need to use the new Windows API functions as well (suffixed with W or 2).
See the last paragraph on https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

[Anders]

Why would I suggest it if it has zero chance of working?

[Mario Emmenlauer]

I agree with @anders_k that similar approaches have been used by other projects in the past, and their mileage was pretty good. For example, ninja (build system) has recently updated their code with the manifest, and have pretty ok long path support.