I suggest you ...

Fix 260 character file name length limitation

The 260 character limit on file paths really gets in the way of having a deeply-nested project hierarchy. It's only there as backwards compatibility with the old school APIs, and has no place in any sort of modern development environment.

We should be able to work with file paths of whatever size we want.

3,002 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Steve LeighSteve Leigh shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    Hello everyone and thank you for the feedback and for voting on this issue. We understand that this can be a frustrating issue, however, fixing it requires a large and complicated architectural change across different products and features including Visual Studio, TFS, MSBuild and the .NET Framework. Dedicating resources to this work item would come at the expense of many other features and innovation. Additionally, if we removed this limitation from our first party tools it will still likely exist elsewhere in Visual Studio’s ecosystem of extensions and tools. For these reasons, we are declining this suggestion and returning return everyone’s votes so they can be applied to other items. In the interest of delivering the most value to our customers we sometimes have to make very difficult cuts, and this is one of them.

    Thank you,

    Will Buik,
    Visual Studio – Project and Build Team

    164 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Colin BowernColin Bowern commented  ·   ·  Flag as inappropriate

        I think you need to start chipping away at this problem. Node.js re-introduces this as well:

        http://stackoverflow.com/questions/23351294/file-path-character-limit-error-in-windows-and-node-app
        https://github.com/joyent/node/issues/6960#issuecomment-46704998

        I had to write a TFS build activity that could handle cleaning up node modules:

        https://gist.github.com/colinbowern/bde095da68f6ee47d296

      • Matthias GoetzkeMatthias Goetzke commented  ·   ·  Flag as inappropriate

        So the reasoning is to not fix it ever because it a lot of work. They could have said we t take out the limitation step by step .. And realistically they should have started doing that years ago. Thru would have finished by now and the few extensions not following this would have been shunned.. But Ms doesn't really have pride in what they deliver. It's a little like s showing the finger to the people that removed this limit from the fs.

      • William BosackerWilliam Bosacker commented  ·   ·  Flag as inappropriate

        @anthonyk: As I told you in the other thread, LPT does nothing for VS or TFS. The limitation is hardcoded into the applications themselves, along with the hard coded limitation of the .NET Framework, and LPT does absolutely nothing to change that.

      • anthonykanthonyk commented  ·   ·  Flag as inappropriate

        Hello,

        Simply download new Long Path Tool software that simply allows you to work easily on Long Path files.

        Thank you.

      • Adam VelebilAdam Velebil commented  ·   ·  Flag as inappropriate

        I can't decide what is more ridiculous - the limitation itself or the fact that the suggestion to fix it was declined.

      • William BosackerWilliam Bosacker commented  ·   ·  Flag as inappropriate

        @James Neave: The majority of us don't map TFS to a folder under "My Documents", we're already using a short path like C:\Work or C:\TFS, and we're still running into the 260 character barrier. Try working on a large web application, or creating multiple libraries, and you'll run into the same problem.

      • James NeaveJames Neave commented  ·   ·  Flag as inappropriate

        Hi,

        One workaround we use is thus:

        We have our Projects folder in My Documents, under that lots of long, descriptive branch names and random failures due to path length.

        But we get around it by mapping the Z: drive to that Projects folder.
        It does cause issues where that drive isn't mapped under all the user accounts you need but I'm sure that could be solved as well.

        We also use it in build scripts for various things, there we use the subst command to point a driver letter at a folder on a local disk.

      • Mark BentleyMark Bentley commented  ·   ·  Flag as inappropriate

        Wow, and 256K is good enough for anyone (Bill Gates). This is a really dumb and out of date limitation. Now I have to impose a poor design on my project tree structure to work around your 1980s path limitations.

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        Large architectural change?!?!
        In any databases instead of *CHARTYPE*(260) use *CHARTYPE*(*REALISTIC-NUMBER*) ..... And in code, instead of fixed length character arrays, malloc some heap space and use char pointers and nul terminated strings. And fix it incrementally in each product as the problem is encountered. How has this bug not slowly gone away over ~15 years of code refactoring/updating/replacement. Are all your file & directory names only 8 characters + 3 character extension, all uppercase... or has that limitation been phased out yet?

      • Anonymous commented  ·   ·  Flag as inappropriate

        All the innovation if we're still haunted by such extreme legacy? Really?

        Many applications could break, but they would still work as long as the paths are within 260 characters.

        What's the drawback? I don't see it.

      • Eric BrownEric Brown commented  ·   ·  Flag as inappropriate

        Given this one was "DECLINED" by Will Buik, the community has responded with: Your reason is not good enough and we STILL want this fixed. Another entry for this item was made here: https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4954037-fix-260-character-file-name-length-limitation#comments Please vote on it so we can hopefully get Will's lame response reversed and have Microsoft address this issue once and for all. Thanks!

      • Anonymous commented  ·   ·  Flag as inappropriate

        Absolutely insane that in this day an age, a 260 char file path limit would be imposed for absolutely no reason whatsoever. We don't NEED "other features and innovation". We need basic functionality to work when expected.

      • Rob ScottRob Scott commented  ·   ·  Flag as inappropriate

        I have to conclude that you have a very poor tightly-coupled architecture. This is pretty surprising given that loose-coupling is Computer Science 101. I will be dropping TFS for version control. Perhaps when you lose enough customers the issue will be "frustrating" enough for you to reconsider.

      • Anonymous commented  ·   ·  Flag as inappropriate

        This limitation also is affecting your OneDrive background sync... so if you are serious about the cloud and sync at Microsoft, you might want to reconsider this major task.

      • Byron BrummerByron Brummer commented  ·   ·  Flag as inappropriate

        Wow, declined?? Seriously?

        Absolutely everything about modern .Net development / Windows development encourages verbose naming and deep nesting, meaning it's trivial to blow past this artificial and freakishly short limit.

        You can't "decline" this major bug and be taken seriously as a development environment. Not in 2014.

      • Eric BrownEric Brown commented  ·   ·  Flag as inappropriate

        Not cool, while I understand that this is a big task, Windows has supported long file names for... how many years now? This is an extremely FRUSTRATING problem to deal with especially when we follow best practices coming straight from Microsoft. This needs to be re-considered and fixed, I'm personally very sick and tired of having to change TFS mappings, get latest, rebuild only to deploy to get around this rather STUPID limitation. Given the volume of votes on this, I don't believe I'm the only one who feels this issue should be addressed. I'm honesty not sure why this issue is even here to begin with as again, Windows has supported long file names since at least Windows 95. FIX THIS!!!

      • NiltonNilton commented  ·   ·  Flag as inappropriate

        Some problems may be hard to solve, but they need to be solved. TFS is a very expensive tool and this limitation is unacceptable. You need to fix it.

      ← Previous 1 3 4 5 8 9

      Feedback and Knowledge Base