Search Issue Tracker
Won't Fix
Votes
0
Found in
2018.1.2f1
Issue ID
1043259
Regression
No
Building fails when trying to build in a folder with too long of a name
How to reproduce:
1. Open the project attached by the user (TumulteStereoTests_Unity2018.1.zip)
2. Go to File --> Build Settings
3. In the Build Settings window, press "Build"
4. Select a folder with a really long name to build in
5. After the building is done, observe the errors in the Console and the build folder
Expected result: The project is built successfully and without errors
Actual result: Errors appear in the Console and the project is not built correctly
Reproducible with: 2017.1.0a1, 2017.1.4f1, 2017.2.3p1, 2017.4.4f1, 2018.1.2f1, 2018.2.0b6
Notes: Building completes with a result of "Failed" in version 2018.2, all other major versions complete the build with a result of "Succeeded". An example folder name used for reproduction would be "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
EDIT: This doesn't sound like a bug but just that they're hitting the windows character limit. Really this is a task to add file path length checking and refuse the path if it's too long if we want to do that. See Marek's comment below.
Comments (1)
-
gutuk
Jun 18, 2019 09:36
It is not the limitation of the OS nor the filesystem.
It is the limitation of the filesystem/OS API which is used.
E.g. Win32 API does not allow more then 256 characters in the full path name. However when using e.g. Unicode API functions, it is possible to use a path of up to 32767 characters.
So I would politely ask you to reconsider "Won't Fix" resolution. It is causing us big troubles when we want to use reasonable tree structure names e.g. "D:\GitLab-Runner\builds\834dc952\0\Products\XXXXXXXXXXXXXXProducts\Proof-Of-Concepts\Assets\XXXXXXXXXXXXXXXXXXXX\XXXXXXXXXXXXXXXXXXXX.Unity2018".
The build then fails on file:
"D:\GitLab-Runner\builds\834dc952\0\Products\XXXXXXXXXXXXXXProducts\Proof-Of-Concepts\Assets\XXXXXXXXXXXXXXXXXXXX\XXXXXXXXXXXXXXXXXXXX.Unity2018\Library\PackageCache\com.unity.analytics@3.2.2\Tests\Editor\Unity.Analytics.StandardEvents\FirstInteractionTests.cs".
with following error message:
"DirectoryNotFoundException: Could not find a part of the path".
As the ..Library\PackageCache\com.unity.analytics@3.2.2\Tests\Editor\Unity.Analytics.StandardEvents\FirstInteractionTests.cs is Unity generated, Unity must already use in some parts of its code API which supports the long paths.
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Inspector elements are rendered twice when the script component is added via drag-and-drop while the HideFlags.HideInInspector property is set
- Error "Light baking failed with error code 5 (Convergence data not available while rendering lightmaps)" thrown in Console when generating lighting for specific GameObjects
- Copy and Paste options for an Animation Property value are disabled in the Right click contextual menu
- Asset is not found when searching the Label "NewLabel" in Search Window
- "Compute dispatch: missing texture ID..." and "Compute dispatch: missing UAV ID..." warnings are thrown after changing the platform in High Definition 3D template
Resolution Note:
the desired fix is to successfully build in a situation where some files deep in the build folder structure will have paths too long for the file system. That cannot be fixed as it's an OS limitation. It sounds like as of 2018.2, the proper fix for this is in place. If you are building with too long a path, it will tell you it fails, rather than the older process of telling you it succeeded, even though it did not.