Long filepaths > 260 characters are not supported - by William Bosacker

Status : 


Sign in
to vote
ID 932051 Comments
Status Active Workarounds
Type Bug Repros 62
Opened 7/29/2014 8:39:50 AM
Access Restriction Public


Q: When does a Feature Limitation become a bug?
A: When the majority of consumers expect the functionality to be different than it actually is.

This is a BUG in the .NET Framework that has existed since its inception over 12 years ago, as it can no longer be considered a Feature Limitation.  The file system and Windows API fully support long filepaths up to 32,767 characters long, as long as each folder name and filename is not more than 255 bytes long.  It is time that the .NET Framework, Visual Studio, Team Foundation Server, etc., also support this.

When working on enterprise applications this becomes an extreme limitation, as it does when working on large web applications.  This BUG MUST BE FIXED!

P.S. Many companies already have SANs and NAS devices that have storage capacities in the petabyte range, and many other companies are heading there as well.  Even DFS (a Microsoft product) supports long file names, which is a major nightmare when your server applications start to crash.  This limitation causes extreme managment and user issues when usage exceeds 260 character file paths, something that ALL of these devices support.
Sign in to post a comment.
Posted by William Bosacker on 6/20/2017 at 10:24 PM
The author of L o n g P a t h T o o l (spelled this way so he doesn't links to his product) is not happy with this being fixed, as he's been making money off of this for over 17 years. If you're using Windows 10, and have the flag turned on, this is no longer a limitation, even in Windows Explorer.
Posted by Valera_ on 6/20/2017 at 8:07 AM
Who voted negatively? Who are they?
Posted by Tarek [MSFT] on 7/7/2016 at 4:40 PM
thanks all for your feedback and patience. this issue is fixed in the coming release 4.6.2.
Posted by Roccoor on 9/23/2015 at 2:48 PM
Just fix that!!!
Posted by .MARK on 9/23/2015 at 7:05 AM
Even one of Microsoft's own projects has had to work around the issue. check out this commit message on an asp.net repository.


Avoid path too long errors when performing BuildV2 builds in MVC repo
- do not glob to the ends of the earth when looking for `project.json` files
Posted by psalmsinger on 7/13/2015 at 6:41 AM
I have seen this also. In fact, as my workaround I keep all my VS projects (2005, 2008, 2010, & 2013) based off the root directory with short directory names, so that I do not see this issue again (i.e. C:\VS2015 Projects\MFC\MFCApplication1.
I wonder if using the "subst" command-line command pointing to a VS Project/Solution directory could also be a workaround.
Posted by The Deeds on 6/6/2015 at 1:29 PM
+1. See the related feedback to Windows team: https://social.technet.microsoft.com/Forums/en-US/e84bb703-27df-4966-bdf1-2b5760c71a1f/filesystem-path-too-long?forum=WinPreview2014Feedback
Posted by .MARK on 5/26/2015 at 9:58 AM
Today, I was backing up files to a network share which took 55 minutes only to have at the last minute the whole operation useless because the destination path would create a path too long. I am now going to backup using a workaround which I should not have had to deal with in the first place. Thanks 260 character limit. I should have used 7-zip from the start knowing this would happen.

"260 character paths is enough for everyone" - Microsoft "Dedicating resources to this work item would come at the expense of many other features and innovations." - Will Buik
Posted by -_Matthias_- on 4/29/2015 at 12:30 PM
It is not possible to use WebDav properly due to this limitation.
Folders and files that exceed the 260 characters filepath limitation fail to show up. Like they wouldnt exist.

The potential workaround to use the backup Windows API (like \\) does NOT work over WebDav!

This is an essiantial issue that should be fixed.

Currently the only workaround that exists to use WebDav with longer filepaths than 260 chars is to use a linux client.
Linux has a path limitation of 4096. So you can use linux to export files over webdav. After that you could burn a DVD (with that exported data) with UDF Format that supports long file paths as well. In the end you could use that dvd on Windows.
Posted by BD Moby Disk on 3/18/2015 at 7:20 AM
This is a problem if you use npm.
Posted by scottgal on 2/26/2015 at 9:50 AM
It's great that this is FINALLY being looked at seriously again. But could you update the UserVoice reports; they're the first hit when you check for this issue. At close to 5000 votes between the 'declined' and still active one you can bet a lot of the community are still watching. I have to say as someone who formerly did triage for incoming bugs for the ASP.NET team I'm kind of amazed at how badly this has been handled.
Posted by Microsoft on 2/25/2015 at 3:55 PM
Hi All,

This item is not resolved and we apologize for the error. We have changed the status back to "Active" and have forwarded this to the appropriate team.

Thank you for understanding!

Meredith Magnusson
Visual Studio Team
Posted by MRR111 on 2/5/2015 at 3:19 PM
The issue is definitely not resolved and should not be marked as a feature request. It has been rejected on UserVoice which is extremely disappointing. Building and executing large enterprise applications for big business data requirements, our products have in excess of 100 projects. The developer IDEs are very tenuously balanced on where the base paths reside due to this limitation. Then factor in checkin builds and other ecosystem dependencies. It is 2015. We have oct-core development machines with 16-32-64GB of memory and terabytes of storage space but Visual Studio is limited to 260 character paths for builds. This problem *could* have been solved over a decade ago but MSFT is sitting on their hands. Until when? When can we expect progressive action in this area?
Posted by nate.r on 10/25/2014 at 10:41 AM
I visited http://azure.microsoft.com/en-us/develop/nodejs/ which linked me to https://nodejstools.codeplex.com/ which crashed Visual Studio Express because of file paths being too long.

I will not consider spending any money on Azure for hosting my Nodejs application nor will I even consider purchasing any edition of Visual Studio until this issue is addressed. I will encourage others to do the same.
Posted by reidca on 10/7/2014 at 9:42 AM
I have just tested Windows Server 10 technical preview build 9481 (which is Windows version 6.4) and I am astonished and disappointed to say this limitation still exists.
Posted by BuildItAllInJS on 8/18/2014 at 8:42 AM
Superb that this problem has been caused on my CI server by one of your own products - the Enterprise Library....*sigh*
Posted by Jeremy D Lee on 8/4/2014 at 12:15 PM
Posted by Microsoft on 7/29/2014 at 6:39 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(<http://support.microsoft.com>)
Posted by esbrown on 7/29/2014 at 10:54 AM
I'm getting rather tired of Microsoft avoiding this issue and having to go to several places to vote on getting this annoyance fixed. This was originally an issue submitted at the "UserVoice" web site and was denied due to "being difficult to fix". The community returned the ball to Microsoft's court by opening another "UserVoice" entry that essentially said, come on guys, fix this.... Now we're having to vote here? When are you guys actually going to do something about this instead of giving us all the run around? Can we please see some traction on this issue once and for all? You guys can give up on trying to deny getting this fixed, the community has made it very clear they want this fixed, myself included. Thanks!
Posted by William Bosacker on 7/29/2014 at 9:34 AM
@Richardo: The moderators here take Trolling very seriously, and I am fully aware of the issue, Thank you. I visited each of your links now, and when they were written 6+ years ago. It is obvious that haven't read them yourself, as they contradict your statements.
Posted by Ricardo Corral on 7/29/2014 at 9:01 AM
This is a feature request not a bug.
I suggest you do some research to better understand how paths work.
This feature has been rejected and will not be implemented.