1293675 - recipe for target 'crashreporter.exe' failed - c:/PROGRA~2/Windows no such file or directory

Status: RESOLVED FIXED

(Toolkit Graveyard :: Build Config, defect)

Description

[Chris H-C :chutten]

The following build failure on ./mach build on my Windows 10 (Anniversary Update) laptop:

 0:52.29 Embedding manifest from c:/msys64/home/Chris/gecko/toolkit/crashreporter/client/crashreporter.exe.manifest
 0:52.32 C:/Users/Chris/AppData/Local/Temp/make13768-1.sh: line 11: c:/PROGRA~2/Windows: No such file or directory
 0:52.34 c:/msys64/home/Chris/gecko/config/rules.mk:656: recipe for target 'crashreporter.exe' failed
 0:52.35 mozmake.EXE[5]: *** [crashreporter.exe] Error 127
 0:52.37 mozmake.EXE[5]: *** Deleting file 'crashreporter.exe'
 0:52.37 c:/msys64/home/Chris/gecko/config/recurse.mk:71: recipe for target 'toolkit/crashreporter/client/target' failed
 0:52.37 mozmake.EXE[4]: *** [toolkit/crashreporter/client/target] Error 2
 0:52.38 mozmake.EXE[4]: *** Waiting for unfinished jobs....

Near as I can tell from looking for "Embedding manifest from", it's using a tool called "mt.exe" from the Windows SDK to do something with manifests.

$ which mt
/c/Program Files (x86)/Windows Kits/8.1/bin/x64/mt.exe

Looks like something 8.3'd the second segment of the path, but didn't do it for the third?

I tried putting a copy of mt.exe in /local/bin so it could be found in a non-space-having part of the path, but no joy. I think something's reading WINDOWSSDKDIR or UNIVERSALCRTSDKDIR or SDKDIR or NETFXSDKDIR or something, and munging it up pretty badly.

Comment 1

[(not currently active) Ted Mielczarek]

Related to bug 1289291 / bug 1289679.

Comment 2

[Mike Hommey [:glandium]]

Please attach the output of mach configure.

Comment 3

[Chris H-C :chutten]

Attachment: `./mach configure` output from failing build

Comment 4

[Mike Hommey [:glandium]]

WTF does GetShortPathNameW not do its job? What version of Windows is this?

Comment 5

[Chris H-C :chutten]

Windows 10 Anniversary Update (Windows build number... Lessee Version 1607 (OS Build 14393.10)

Comment 6

[Gregory Szorc [:gps]]

I'm unable to reproduce on Windows 10 Anniversary Update Build 14393. I'm getting 8.3 paths for all path components, not just the leading one.

Comment 7

[Mike Hommey [:glandium]]

Do you have an antivirus installed or something else that would alter GetShortPathNameW's behavior?

Comment 8

[Chris H-C :chutten]

Windows Defender and Kaspersky Endpoint Security 10.

Comment 9

[Chris H-C :chutten]

Hm. Apparently Kaspersky Endpoint Security 10, though appearing to be installed, isn't running a service.

Comment 10

[Chris H-C :chutten]

Attachment: Test program for GetShortPathNameW

Well, indeed it is GetShortPathName that's to blame, as the attached program generates (for me) 

long name = C:\Program Files (x86)\Windows Kits\8.1\ shortname = C:\PROGRA~2\Windows Kits\8.1\

(( So too it does if I ask it to use just GetShortPathName ))

Well, I have a pending Windows Update. Let's see if that shakes things back into order.

Comment 11

[Molly Howell (she/her) (mostly inactive)]

On the Windows 10 Anniversary update, the test program generates:

long name = C:\Program Files (x86)\Windows Kits\8.1\ shortname = C:\PROGRA~2\WI3CF2~1\8.1\

Comment 12

[Chris H-C :chutten]

Attachment: dir /X and fsutil 8dot3name query

Ah-ha!

c:\Program Files (x86)>fsutil 8dot3name query
The registry state is: 1 (Disable 8dot3 name creation on all volumes).

At some point (probably during the update) 8dot3 name creation was disabled on my volumes. Let's see if I can fix that...

Comment 13

[Chris H-C :chutten]

fsutil behavior set disable8dot3 2

fsutil file setshortname "Windows Kits" WI3CF2~1

echo "Fingers Crossed" && ./mach build

Comment 14

[Gregory Szorc [:gps]]

`mach doctor` prompts the user to disable 8.3 filename creation... for performance reasons.

We may want to remove that.

Comment 15

[Chris H-C :chutten]

Filed bug 1294475 to track the `mach doctor` bits.

./mach build failed possibly because I forgot to refresh the configuration. So now it's

echo "Fingers Crossed" && ./mach configure && ./mach build

Comment 16

[Chris H-C :chutten]

That did it. Actually able to build and run now.

Sorry for the noise.

Comment 17

[Mike Hommey [:glandium]]

Actually, I think we should error out directly in configure if GetShortPathName gives out paths with spaces, at least until the build system is able to deal with them.

Comment 20

[Mike Hommey [:glandium]]

Attachment: Bug 1293675 - Error out when GetShortPathName returns a long path name.

Review commit: https://reviewboard.mozilla.org/r/89664/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/89664/

Comment 21

[Gregory Szorc [:gps]]

Comment on attachment 8806165 [details]
Bug 1293675 - Error out when GetShortPathName returns a long path name.

https://reviewboard.mozilla.org/r/89664/#review89082

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6c105cd2bf71
Error out when GetShortPathName returns a long path name. r=gps

Comment 23

[Phil Ringnalda (:philor)]

Backed out in https://hg.mozilla.org/integration/autoland/rev/779677281c0584c1f6452be4d4c36238fb11bb67 for, e.g., https://treeherder.mozilla.org/logviewer.html#?job_id=5943900&repo=autoland

Comment 24

[Mike Hommey [:glandium]]

Comment on attachment 8806165 [details]
Bug 1293675 - Error out when GetShortPathName returns a long path name.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/89664/diff/1-2/

Comment 25

[Mike Hommey [:glandium]]

Comment on attachment 8806165 [details]
Bug 1293675 - Error out when GetShortPathName returns a long path name.

With adjusted unit tests so that they don't fail because of the new check.

Comment 26

[Gregory Szorc [:gps]]

Comment on attachment 8806165 [details]
Bug 1293675 - Error out when GetShortPathName returns a long path name.

https://reviewboard.mozilla.org/r/89664/#review89314

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7eed7e4fda99
Error out when GetShortPathName returns a long path name. r=gps

Comment 28

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/7eed7e4fda99