New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Light fails with error about not finding a directory #5809

Open
kskalski opened this Issue May 11, 2018 · 19 comments

Comments

Projects
None yet
6 participants
@kskalski
Copy link

kskalski commented May 11, 2018

Windows Installer XML Toolset Linker version 3.11.1.2318 (I also tested with 3.10.3, but has the same problem)
.NET 4.6.1
When building installer for my project I get following error:
$ /mnt/c/Program\ Files\ (x86)/WiX\ Toolset\ v3*/bin/light.exe -v -cultures:en-us -ext WixUtilExtension -ext WixNetFxExtension -out Elector.msi K
ogut.wixobj
Windows Installer XML Toolset Linker version 3.11.1.2318
Copyright (c) .NET Foundation and contributors. All rights reserved.

Updating file information.
Creating cabinet files.
There will be '8' threads used to produce CAB files.
Creating cabinet 'C:\Users\kamil\AppData\Local\Temp\m4u1ywwz#Sample.cab'.
light.exe : error LGHT0001 : System nie może odnaleźć określonej ścieżki. (Wyjątek od HRESULT: 0x80070003)

Exception Type: System.IO.DirectoryNotFoundException

Stack Trace:
w Microsoft.Tools.WindowsInstallerXml.Cab.Interop.NativeMethods.CreateCabFinish(IntPtr contextHandle, IntPtr newCabNamesCallBackAddress) w Microsoft.Tools.WindowsInstallerXml.Cab.WixCreateCab.Complete(IntPtr newCabNamesCallBackAddress) w Microsoft.Tools.WindowsInstallerXml.CabinetBuilder.CreateCabinet(CabinetWorkItem cabinetWorkItem) w Microsoft.Tools.WindowsInstallerXml.CabinetBuilder.ProcessWorkItems()

No errors should be present, actually I had this project build correctly on my older dev machine with older WiX

The error seems a bit similar to #5677, but I don't think it's related - I don't have any subdirs or relative paths in any "Name" attribute.

Setting WIX_TEMP changes the output path for temporary cabinet file, but the same error persists.

@barnson

This comment has been minimized.

Copy link
Member

barnson commented May 24, 2018

This functionality is generally working so there's something odd about the environment. What happens from cmd.exe or PowerShell? You can also use the wix311-debug.zip symbols to debug and track where the \ changes to a #.

@kskalski

This comment has been minimized.

Copy link

kskalski commented May 25, 2018

Output from cmd.exe:

"c:\Program Files (x86)\WiX Toolset v3.11\bin\light.exe" -cultures:en-us -ext WixUtilExtension -ext WixNetFxExtension -out Elector.msi Kogut.wixobj -v Windows Installer XML Toolset Linker version 3.11.1.2318 Copyright (c) .NET Foundation and contributors. All rights reserved.

Updating file information. Creating cabinet files. There will be '8' threads used to produce CAB files. Creating cabinet 'C:\Users\kamil\AppData\Local\Temp\a2dbywzl\#Sample.cab'. light.exe : error LGHT0001 : System nie może odnaleźć określonej ścieżki. (Wyjątek od HRESULT: 0x80070003)

Exception Type: System.IO.DirectoryNotFoundException

Stack Trace: w Microsoft.Tools.WindowsInstallerXml.Cab.Interop.NativeMethods.CreateCabFinish(IntPtr contextHandle, IntPtr newCabNamesCallBackAddress) w Microsoft.Tools.WindowsInstallerXml.Cab.WixCreateCab.Complete(IntPtr newCabNamesCallBackAddress) w Microsoft.Tools.WindowsInstallerXml.CabinetBuilder.CreateCabinet(CabinetWorkItem cabinetWorkItem) w Microsoft.Tools.WindowsInstallerXml.CabinetBuilder.ProcessWorkItems()

output from PowerShelll:
& 'C:\Program Files (x86)\WiX Toolset v3.11\bin\light.exe' -cultures:en-us -ext WixUtilExtension -ext W ixNetFxExtension -out Elector.msi Kogut.wixobj -v Windows Installer XML Toolset Linker version 3.11.1.2318 Copyright (c) .NET Foundation and contributors. All rights reserved.

Updating file information. Creating cabinet files. There will be '8' threads used to produce CAB files. Creating cabinet 'C:\Users\kamil\AppData\Local\Temp\syxm4r05\#Sample.cab'. light.exe : error LGHT0001 : System nie może odnaleźć określonej ścieżki. (Wyjątek od HRESULT: 0x80070003)

Exception Type: System.IO.DirectoryNotFoundException

Stack Trace: w Microsoft.Tools.WindowsInstallerXml.Cab.Interop.NativeMethods.CreateCabFinish(IntPtr contextHandle, IntPtr newCabNamesCallBackAddress) w Microsoft.Tools.WindowsInstallerXml.Cab.WixCreateCab.Complete(IntPtr newCabNamesCallBackAddress) w Microsoft.Tools.WindowsInstallerXml.CabinetBuilder.CreateCabinet(CabinetWorkItem cabinetWorkItem) w Microsoft.Tools.WindowsInstallerXml.CabinetBuilder.ProcessWorkItems()

Actually, the lack of \ in the output is github's artifact, the \ is actually there in the text (now also visible with proper code format). Also, when I edit Kogut.wixobj to change "#Sample.cab" to "Sample.cab", it's like following:
Creating cabinet 'C:\Users\kamil\AppData\Local\Temp\t1mgca3w\Sample.cab'. light.exe : error LGHT0001 : System nie może odnaleźć określonej ścieżki. (Wyjątek od HRESULT: 0x80070003)

Exception Type: System.IO.DirectoryNotFoundException

Basically it looks like light.exe is not creating the temporary subdir. Something like this might happen maybe due to permissions, but running it as administrator doesn't help and the dirs seem to have proper permissions anyway.

@kskalski

This comment has been minimized.

Copy link

kskalski commented Jun 2, 2018

I got it reproduced on another machine, and in the same set-up it works on the third machine. The difference between them is that both machines where the problem occurs have Windows 10 April 2018 Update + WSL installation

@barnson barnson added the bug label Jun 7, 2018

@BMurri

This comment has been minimized.

Copy link
Collaborator

BMurri commented Jun 11, 2018

I'm running Windows 10 April 2018 Update + WSL installed and I've never seen this error. There's got to be more to this. What do the TEMP & TMP environment vars look like?

@kskalski

This comment has been minimized.

Copy link

kskalski commented Jun 12, 2018

Neither TEMP nor TMP vars are set in the environment. Setting them doesn't help though, both light.exe and regenerating .wixobj with candle.exe+light.exe produce the same output - they show the supposed .cab path that is going to be created, but then fail on doing so. They complain that the "directory doesn't exist", not sure which, but indeed parent directory (like 'C:\Users\kamil\AppData\Local\Temp\t1mgca3w' does not exist, even though 'C:\Users\kamil\AppData\Local\Temp' does).

I attach the stripped spec of my installer that still reproduces this problem. It only depends on single file in reldist/Elector.exe, so should be easy to run.

Kogut.zip

@jchoover

This comment has been minimized.

Copy link
Collaborator

jchoover commented Jun 14, 2018

Are you trying to invoke light/cmd/powershell from within BASH instead of a regular command prompt?

FYI, installed WSL and Ubuntu. Updated to latest Ubuntu.

From Bash, rand Candle and Light without issue against your wxs.


@kskalski

This comment has been minimized.

Copy link

kskalski commented Jun 14, 2018

I have the same error from BASH (Ubuntu on WSL), cmd.exe and PowerShell, on two laptops and on Win10 VM.
Hm, could this be related to the drive name? When I copy my wxs file to my homedir on C: it works ok, but in my project directory on D: it fails

@kskalski

This comment has been minimized.

Copy link

kskalski commented Jun 14, 2018

Ok, not a drive name (it also fails on a custom directory on C:), but there must be something with the location. Maybe permissions on the output directory.

@kskalski

This comment has been minimized.

Copy link

kskalski commented Jun 15, 2018

The difference occurs in current working directory, running the same command reading and writing to the same location fails when run from C:\installs but succeeds in C:\imports. The directories have the same permissions and write settings (from the looks of it), I can't see what makes them behave differently.

PS C:\installs> & 'C:\Program Files (x86)\WiX Toolset v3.11\bin\light.exe'  -out 'C:\Users\kamil\Elector.msi' 'C:\Users\
kamil\Kogut.wixobj' -v
Windows Installer XML Toolset Linker version 3.11.1.2318
Copyright (c) .NET Foundation and contributors. All rights reserved.

Updating file information.
Creating cabinet files.
There will be '8' threads used to produce CAB files.
Creating cabinet 'C:\Users\kamil\AppData\Local\Temp\ob0q3v0g\#Sample.cab'.
light.exe : error LGHT0001 : Nie można odnaleźć określonego pliku. (Wyjątek od HRESULT: 0x80070002)

Exception Type: System.IO.FileNotFoundException

Stack Trace:
   w Microsoft.Tools.WindowsInstallerXml.Cab.Interop.NativeMethods.CreateCabFinish(IntPtr contextHandle, IntPtr newCabNamesCallBackAddress)
   w Microsoft.Tools.WindowsInstallerXml.Cab.WixCreateCab.Complete(IntPtr newCabNamesCallBackAddress)
   w Microsoft.Tools.WindowsInstallerXml.CabinetBuilder.CreateCabinet(CabinetWorkItem cabinetWorkItem)
   w Microsoft.Tools.WindowsInstallerXml.CabinetBuilder.ProcessWorkItems()
PS C:\installs> cd ..
PS C:\> cd .\import\
PS C:\import> & 'C:\Program Files (x86)\WiX Toolset v3.11\bin\light.exe'  -out 'C:\Users\kamil\Elector.msi' 'C:\Users\ka
mil\Kogut.wixobj' -v
Windows Installer XML Toolset Linker version 3.11.1.2318
Copyright (c) .NET Foundation and contributors. All rights reserved.

Updating file information.
Creating cabinet files.
There will be '8' threads used to produce CAB files.
Creating cabinet 'C:\Users\kamil\AppData\Local\Temp\0mvolla0\#Sample.cab'.
Generating database.
Merging modules.
Validating database.
...
ICE57: Created 02/11/1999. Last Modified 01/17/2000.
PS C:\import>
@jchoover

This comment has been minimized.

Copy link
Collaborator

jchoover commented Jun 15, 2018

Any chance of getting a procmon log of light when it fails?

@kskalski

This comment has been minimized.

Copy link

kskalski commented Jun 18, 2018

Attached procmon log from failed and successful execution of light
light_procmon_log.zip

@jchoover

This comment has been minimized.

Copy link
Collaborator

jchoover commented Jun 18, 2018

Is it intentional that C:\installs\reldist\Elector.exe exists, but C:\import\reldist\Elector.exe does not? In the case of your successful example it's coming from C:\Users\kamil\reldist\Elector.exe.

I am wondering if this is related to the bundle having the same name as a payload, along with files that exist in one folder but not the other.

IRP_MJ_CREATE,C:\installs\reldist\ELECTOR.EXE,NAME NOT FOUND,"Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a"

vs

IRP_MJ_CREATE,C:\Users\kamil\reldist\Elector.exe,SUCCESS,"Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened"

@kskalski

This comment has been minimized.

Copy link

kskalski commented Jun 18, 2018

Confirmed, this is the differentiator - when I remove reldist/Elector.exe from c:\installs, then the build succeeds from that directory.

In normal scenario I build ./Elector.msi in working directory and reference file in ./reldist/Elector.exe, but apparently it somehow messes up with what light.exe does. It's pretty weird, since in the working case:

  • used .wixobj file is in c:\Users\kamil\Kogut.wixobj
  • output is to c:\Users\kamil\Elector.msi
  • effective referenced file is in c:\Users\kamil\reldist\Elector.exe (in .wxs the reference is relative, to "reldist/Elector.exe")
  • the file that can't be present is .\reldist\Elector.exe (it's arguable if this file should be accessed, the reference is relative, so it might mean relative to working dir, but the one used is actually relative to .wixobj file)

Do you mean trying to changes names for .msi or some id in wxs?

@jchoover

This comment has been minimized.

Copy link
Collaborator

jchoover commented Jun 18, 2018

Sorry, Forget the name part, as I was for some reason thinking you were generating a bundle.

One observation, in the fail case, the file name is all uppercase.

Can you run:
fsutil.exe file queryCaseSensitiveInfo C:\installs\reldist

@kskalski

This comment has been minimized.

Copy link

kskalski commented Jun 18, 2018

I renamed that directory to do my last test, though probably that didn't change the attributes:

PS C:\installs> fsutil.exe file queryCaseSensitiveInfo C:\installs\reldista
Case sensitive attribute on directory C:\installs\reldista\ is enabled.
PS C:\installs> fsutil.exe file queryCaseSensitiveInfo C:\installs
Case sensitive attribute on directory C:\installs\ is disabled.

@jchoover

This comment has been minimized.

Copy link
Collaborator

jchoover commented Jun 21, 2018

With the relative file in place, what happens if you run fsutil.exe file SetCaseSensitiveInfo C:\installs\reldista disable

@kskalski

This comment has been minimized.

Copy link

kskalski commented Jun 22, 2018

I had to run fsutil command as administrator, since as regular user I had access denied, but indeed after that operation the failing scenario started to work (as regular user, building from c:\installs)

@jchoover

This comment has been minimized.

Copy link
Collaborator

jchoover commented Aug 2, 2018

dutil,
cabcutil.cpp
CabCAddFile"

    hr = StrAllocString(&sczUpperCaseFile, wzFile, 0);
    ExitOnFailure1(hr, "Failed to allocate new string for file %ls", wzFile);

    // Modifies the string in-place
    StrStringToUpper(sczUpperCaseFile);

Adding the file makes its name all upper case, but then in CabCFinish, the call to FCIAddFile fails because it's using the upper cased value.

@barnson barnson added this to the v4.0 milestone Aug 16, 2018

@barnson barnson added the binder label Aug 16, 2018

@131

This comment has been minimized.

Copy link

131 commented Jan 17, 2019

After more tests i can say

  • on win 10.0.17134.345 a folder created through WSL produce the 0x80070003 error

  • on win 10.0.17134.345 a folder created through explorer.exe works fine

  • on 10.0.17763.253, both cases are working fine

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment