Inno Setup Compiler "Cannot find the path specified" error with long paths

Question

I am using a .iss script to build an exe file inside Inno Setup Compiler. I need to package some node_modules into this application so I have a line under [Files] which looks like this:

Source: "{#SourcePath}Encore.Warehouse.UI\bin\Warehouse_Release\warehouse\*"; \
    DestDir: "{app}\warehouse"; Flags: ignoreversion recursesubdirs createallsubdirs

When I compile, I receive this error:

Here is the compiler output:

So, it appears to be running fine up until it aborted. My initial thought was that the browser.js doesn't exist but after double checking, this is not the case. Also, I'm using a wildcard in the source path so the compiler knows the file exists, but it seems to be having trouble compressing it.

One other thing that could be causing the issue is the file path length. Node modules usually end up having ridiculous file path lengths due to nested dependencies. In this case, the path length is 260. Assuming this is what's causing the problem, is there any way to get around it?

Answer 1

It's definitely due to a long path. Normally Windows applications cannot process paths longer than MAX_PATH (260 characters).
See Naming Files, Paths, and Namespaces in Microsoft documentation.

A common workaround is prefixing the path with \\?\ (again see the Microsoft article above). The prefix can be used for absolute paths only. But Inno Setup compiler chokes on that with the Source attribute. It looks for : and it accepts only path that either have a drive letter only before the : or that use compiler: or userdocs: prefixes.

You can hack that by using an UNC path with a volume ID (hence no colon).

Use the mountvol command to find the UNC path for your source drive.

And then you will have the same problem with a long path with the DestDir attribute, while installing (not when compiling). There, there's no problem with the colon, so you can simply use the \\?\ prefix.

Source: "\\?\Volume{bb919c3e-bdb1-42b8-9601-6715becd8683}\{#SourcePath}Encore.Warehouse.UI\bin\Warehouse_Release\warehouse\*"; \
    DestDir: "\\?\{app}\warehouse"; Flags: ignoreversion recursesubdirs createallsubdirs

---

Of course, if the problem is caused by a root path being too long already, you can fix the problem simply be moving the source files to a folder with a shorter path. Or you can use subst to create a virtual drive or you can create a symlink/directory junction.

Answer 2

Falling into the same issue, here below is more details on workaround with subst as described in comments and accepted answer.

Here below is content of some precompile.bat file to associate some local path with the A: drive letter

@echo off
REM NB: Removing any previous association to be sure new one will work
subst A: /D 1> NUL 2>&1
subst A: "%~dp0.."

And content of some postcompile.bat to remove association in the end

@echo off
subst A: /D 1> NUL 2>&1

NB1: Careful, once associated, it is difficult to navigate upper paths directly within the .iss script because A:\.. is still A:\ ! (I fall into the issue, so worth to know). Association should then be made with closest top-most folder of all required files directly in precompile.bat.

NB2: I don't know if feasible to remind for any previous association and restore it in the end

These steps can be added to the .iss script as follow:

[PreCompile]
Name: "precompile.bat"; Flags: cmdprompt redirectoutput

[PostCompile]
Name: "postcompile.bat"; Flags: cmdprompt redirectoutput

Note finally that [PreCompile] and [PostCompile] sections will execute from the IDE only. They won't execute from the command line (at least with inno 5.5.9), I also fall into this... so complete compilation from command line should look like:

call "precompile.bat"
call "%ProgramFiles(x86)%\Inno Setup 5\ISCC.exe" "myscript.iss"
call "postcompile.bat"

NB: I think calling Compil32.exe /cc "myscript.iss" (IDE compiler) instead of ISCC.exe (command-line compiler) should run [PreCompile] and [PostCompile] sections but in my case I had to pass extra /D options to the compiler so it was not possible to call Compil32.exe directly.