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.
-
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
- Crash on ShaderLab::ShaderState::ApplyShaderState when entering Play Mode and calling ShaderWarmup.WarmupShaderFromCollection with a shader that has dynamic_branch
- Crash on operator delete[] when a serializable structure in the System namespace is serialized by a MonoBehaviour
- [macOS] forward and backward mouse buttons are recognized as middle mouse button
- NavMeshModifier.OnEnable/OnDisable gets progressively slower when called repeatedly
- "System.Net.CookieContainer" throws an "ArgumentException" error when using a non-UTF-8 machine locale and hostname
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.