Mike Parks

"If you want to be the best, you've got to work with the best"
posts - 12, comments - 6, trackbacks - 0

My Links

News

Archives

Team Build 260 Character Path Limit Workaround

We've recently implemented a new branching strategy for our Team Foundation Server's Source Control. It was a great idea that's working out well but it caused a few problems with our Continuous Integration builds.  The builds were failing with this error:

The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

It's a pretty common error and I'm sure most of you build engineers have seen this before. Keep in mind that this is not a TFS limitation, it is caused by a Windows limitation.  An easy way to fix this it to change the working directory of your Build Agent:

  1. In your Team Explorer 2008 window, right click on the Builds folder
  2. Click on Manage Build Agents
  3. Make sure your build agent is highlighted and click the Edit button
  4. Change the default working directory from $(Temp)\$(BuildDefinitionPath) to C:\b\$(BuildDefinitionId)


This will give you a lot of extra characters for your build server to work with.  The file path still needs to be under 260 characters though.  If you're wondering which C drive this references, it's the C drive on your build server. By changing this I've shortened the working directory path:

  • From: C:\Documents and Settings\tfsBuild\Local Settings\Temp\MikeTFS\Development - MikesProgram
  • To:      C:\b\1
You can delete everything out of the old working directory to free up some space on the build server if you're no longer using those builds.


So that should fix the issue. I did also want to give a little more information on working directories. Working directories are stored on your build server.  The working directory can be referenced by each build definition. Each time a new build is queued, a working directory folder will be created or modified under C:\b\$(BuildDefinitionID). Three sub folders are created inside this working folder (Binaries, BuildType, and Sources):

Binaries
folder: Contains the binary output from the build
BuildType
folder: Contains the build log and MSBuild files (TFSBuild.proj, TFSBuild.rsp, TFSBuild.tbrsp)
Sources folder: Contains the files downloaded to the build server mapped by the build definition you set up. See below.

For example, for the sources folder, TFS will perform a GET on the workspace you specify in the build definition and place all the files into $(SourceDir), which in our case would be C:\b\1\Sources. It uses these files to build your application on the build server. So it's important that each build definition is mapped out correct. You can also only map the workspace working folders that you need in order to speed up your build.




Hope this helps! Leave me some feedback if you get a chance.  Thanks everyone.

- Mike

 

Print | posted on Saturday, June 20, 2009 12:40 PM |

Feedback

Gravatar

# re: Team Build 260 Character Path Limit Workaround

Hi Mike,

You're right, this is not an inherent limitation in TFS, any build system could have been affected by exceeding the max path length on windows.

Thanks for the tips!

Mr. Hericus
6/20/2009 3:56 PM | Mr. Hericus
Gravatar

# re: Team Build 260 Character Path Limit Workaround

Unfortunately I have to disagree - it isn't a Windows limitation, it's a TFS limitation inherited from using the .NET Framework.

Why do I disagree although the linked MSDN article states exactly the same? Well, it depends on how you use the Windows API. You can pass standard filenames as the .NET Framework does in all operations which limits you to 260 characters. Or you can use the "\\?\" prefix practically everywhere and extend the limitation to 32,767 characters. Because the .NET Framework had to run on Win98 and WinME (which only support 260 chars) they chose to implement it that way. Now everybody using file operations on .NET is bound to those limits because there's no way to support 'long long filenames' in applications without using P/Invoke everywhere... :-(

What can TFS do about it? Nothing. At least not in their code base. But they could try to push the .NET BCL Team to support the full Windows limit when passing file names with the respective prefix.
6/29/2009 12:14 PM | Ooh
Gravatar

# re: Team Build 260 Character Path Limit Workaround

Good description!
8/11/2009 12:02 PM | Dan
Post A Comment
Title:
Name:
Email:
Website:
Comment:
Verification:
 
 

Powered by: