3 Tricks for Shrinking Windows File Paths
May 21, 2015
If you write a Windows application that interacts with the file system, there’s a hidden trap you need to know about. In a Windows environment, your file path cannot exceed 260 characters in length. In layman’s terms, that means…
…has to be less than 260 characters. That might seem easy, but in some cases, your application is already being hosted within a depth you may not expect, such as:
And that would occur before you begin to build your own folder structure. To be more specific, the usable limit is 256 characters as the leading drive letter and a trailing character exist in the path. So it’s easier to run out of room than you might guess.
The Windows API, responsible for abstracting all file/folder access for Windows applications, enforces this limit, meaning that every application that accesses files and folders may behave unexpectedly when it attempts to leverage a path exceeding this limit.
For instance, when trying to publish an Azure Web App using Visual Studio with a solution that is nested too deeply, the following is shown within the error log.
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.
C:Program Files (x86)MSBuildMicrosoftVisualStudiov12.0Windows Azure Tools2.4Microsoft.WindowsAzure.targets
Luckily, the developers behind Visual Studio had the foresight to explicitly check for this limitation prior to continuing the deployment, to both inform the developer to resolve it prior to continuing and not attempt a deployment that will undoubtedly fail.
Here are three documented workarounds:
Copy the full working folder containing the solution file from its depth down into the root folder of the drive.
Example: C:ThisPathIsLengthyAndDeploymentFailsSolution.sln would be moved to C:ASolution.sln temporarily, the deployment performed, then revert the change (if necessary).
Leverage the ‘subst’ command to assign a drive letter to the folder containing the solution file. This option is definitely more desirable than Option 1 since the files do not actually need to be moved.
Example: subst Z: C:ThisPathIsLengthyAndDeploymentFails
Create a symbolic link to the folder. Similar to Option 2, the files will remain accessible at the longer path but also be accessible at the shorter path.
Example: mklink /D C:A C:ThisPathIsLengthyAndDeploymentFails
Once the secondary route to the solution file is established, simply re-open the solution from the shorter path and, assuming your path is now short enough to fit within the path length limit, your deployment should go through without any problem.
Stay up to date with our email updates!