Error message from build "GetShortPathName returned a long path name. Are 8dot3 filenames disabled?"
Categories
(Firefox Build System :: General, task, P3)
Tracking
(Not tracked)
People
(Reporter: pls, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36
Actual results:
When running on Windows, the build systems requires that the file paths it deal with either fit the 8dot3 name pattern or have alternate 8dot3 name present. If it finds a path where neither of these is true, you get an error message from util.configure:
GetShortPathName returned a long path name.
5Are 8dot3 filenames disabled?
Yes, there are bugs such as Bug 1323381 which suggest that the error message should say different things.
There are a lot of developers whose experience does not extend back to the days of 8dot3 file names. The ways in which Windows handles these names and reasons why the build system requires them are both complex and subtle. It is simply not reasonable to provide the required information in an error message.
Therefore, I suggest that the error message be this:
The file path <path>
is missing a required short (8dot3) file name. Please see the article at
http://developer.mozilla.org/xxxxxxx
for more information and how to resolve the problem.
If this bug is accepted, I will provide the article.
![]() |
||
Comment 1•6 years ago
|
||
Thanks for volunteering!
Reporter | ||
Comment 2•6 years ago
|
||
Not a problem. I just don't want to do the article until I know that this is the way you want to handle this. Fixing the build system to not need the short names would be better, but (for reasons I don't understand) that seems to be a hard problem. Still, at this point Microsoft is deprecating short file names, so the clock is ticking.
![]() |
||
Comment 3•6 years ago
|
||
(In reply to Paul Schauble from comment #2)
Not a problem. I just don't want to do the article until I know that this is the way you want to handle this. Fixing the build system to not need the short names would be better, but (for reasons I don't understand) that seems to be a hard problem. Still, at this point Microsoft is deprecating short file names, so the clock is ticking.
Investigating this a bit suggests that short file names are not enabled by default on non-C:\ drives for newer Windows builds; C:\ still has them enabled. Depending on what you write, it may be worth calling this out and suggesting that people install their toolchain in the standard place.
I don't think this implies "this clock is ticking", though.
Reporter | ||
Comment 4•6 years ago
|
||
I recently installed Windows 10 v1809 in a virtual machine and I have exactly what you described:
- The global setting for short names is per-drive.
- C: has short names enabled.
- My D: (software) and E: (Data) drives have short names disabled.
My main machine, which was automatically upgraded to 1809, had the same until I changed it.
I hit the error message because I had the Windows SDKs installed on D: and had to add short names to the path to them.
![]() |
||
Comment 5•4 years ago
|
||
Has the Windows configuration for drive C: changed recently? At least two volunteers mentioned the issue in the last month, and one mentioned that C: got used.
Updated•3 years ago
|
Description
•