The specified path, file name, or both are too long

[IanG]

Hi Some of our users are getting the error "The specified path, file name, or both are too long." when getting our code out, as far as we can tell none of our files should produce a path longer than the 248 character limit but we are still getting this error. Unfortunately the error does not report the name of the file that is causing the error so we are at a bit of a loss as to what to do.
We would rather not force people to move their build folders nearer the root as they are not that far from root anyway, (most are something like d:\build\Version6\ )

I have seen this item: viewtopic.php?f=5&t=20183 which suggests moving the cache folder location but again it doesn't look like the cache files should be generating a file name in excess of 248 characters.
Any help would be most appreciated.
Ian.

[Beth]

When setting working folders, if the working folder is set at $ and then goes to a long disk path, such as C:\Users\Username\Documents\some folder\some folder\etc, then the full path as one goes through the tree is $ + whatever path to the lowest level file + C:\Users\Username\Documents\some folder\some folder\etc. That means once it gets to $/a/b/c/d/e/f/g/h/file.txt, the actual path to consider is C:\Users\Username\Documents\some folder\some folder\etc\a\b\c\d\e\f\g\h\file.txt.

What a user can do is they can keep their working folder set, but at a lower level override the working folder inheritance and set it at a lower level as well and see if that helps.

[IanG]

Hi,
Thanks for the reply, unfortunately that doesn't really help, we don't want to micro manage each project to force it lower in the folder structure and we need a sensible way to organize things anyway. Our repository structure looks like this:

Code: Select all

$¬-Branches¬-V1--Source¬-Bin
 |         |           |-Server¬-Common¬-CommonAssembly1¬-Namespace1
 |         |           |       |       |                L-Namespace2
 |         |           |       |       L-CommonAssembly2
 |         |           |       |      
 |         |           |       |-DataLayer¬-DataAssembly1
 |         |           |       |          |-DataAssembly2
 |         |           |       |          L-DataAssembly3
 |         |           |       |      
 |         |           |       |-LogicLayer¬-LogicAssembly1
 |         |           |       |           |-LogicAssembly2¬-Namespace1¬-ClassFolder1¬-Class1
 |         |           |       |           |               |           |             |-Class2
 |         |           |       |           |               |           |             L-Class3
 |         |           |       |           |               |           L-ClassFolder2
 |         |           |       |           |               L-Namespace2
 |         |           |       |           L-LogicAssembly3
 |         |           |       |      
 |         |           |       L-ServiceLayer¬-ServiceAssembly1
 |         |           |                     |-ServiceAssembly2
 |         |           |                     L-ServiceAssembly3
 |         |           |
 |         |           |-Presentation
 |         |           |-ThirdParty
 |         |           L-Utilities
 |         |-V2
 |         L-V3
 L-Trunk¬-Source¬-Bin
                |-Server¬-Common¬-CommonAssembly1
                |       |       L-CommonAssembly2
                |       |-DataLayer¬-DataAssembly1
                |       |          |-DataAssembly2
                |       |          L-DataAssembly3
                |       |      
                |       |-LogicLayer¬-LogicAssembly1
                |       |           |-LogicAssembly2
                |       |           L-LogicAssembly3
                |       L-ServiceLayer¬-ServiceAssembly1
                |                     |-ServiceAssembly2
                |                     L-ServiceAssembly3
                |
                |-Presentation
                |-ThirdParty
                L-Utilities

The working folder for $ will be set to something like D:\Build\gui300 so i don't think we are using an excessively deep folder structure, especially as we need to be able to work on multiple versions at the same time.
I note that Microsoft have made some steps to enable working around the path length problem in windows 10:
https://blogs.msdn.microsoft.com/jeremy ... indows-10/

Can vault be configured/modified to work with the new long path support?

[Beth]

I have a feature request open I can add your vote to.

In the meantime, let's turn on debug logging to try and identify the approximate location. Use the KB articles Using Debug Logging for Troubleshooting to set up your logging. you can then either post your logs here or you can email them to support at sourcegear.com.

[hwapdc]

Hi
Is there any news regarding Vault (Vault Server and Vault Clients) supporting long file path (beyond the old 260 char limit). Windows 10 and Windows 2016 now supports file path longer than 260 chars (Enable Win32 long paths).

[Beth]

The MAX_PATH limitation of 260 characters is tied to the Win32 API and .Net, which also sets the restrictions for Vault. Another work-around is to create junctions so that Vault has a shorter path.

[jclausius]

Hi,
Thanks for the reply, unfortunately that doesn't really help, we don't want to micro manage each project to force it lower in the folder structure and we need a sensible way to organize things anyway.

<snip>

The working folder for $ will be set to something like D:\Build\gui300 so i don't think we are using an
excessively deep folder structure, especially as we need to be able to work on multiple versions at the same time.

IanG, You mention your paths are below the 260 (MAX_PATH) limit. But it could be one of the baseline files Vault stores in _sgvault. What setting are you using forLocal Files -> Cache Location -> Store Working Folder State / Baseline Files ?

If the settings are to store in the Working Folder, adding "_sgvault\<some_object_id>" might push it past the MAX_PATH limit.