I suggest you ...

1,302 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…)
    ScottLanghamScottLangham shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    30 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...
      • Jim PalavrosJim Palavros commented  ·   ·  Flag as inappropriate

        Can anyone confirm that the "Long Path Tool" Software really works? If so, can I get a link. I don't want to play around with any downloads that may have different intentions.

        Thanks

      • William BosackerWilliam Bosacker commented  ·   ·  Flag as inappropriate

        Hey All, this "Long Path Tool" does absolutely nothing for us, and the author of the tool spams it all over the place, like the message below. This issue has been around for over 12 years, so I have created an issue on Microsoft Connect to fix this BUG! If everyone would go to the URL below, login, and Click the up arrow to vote for this, Microsoft will be forced to respond. While these uservoice forums are helpful, they aren't actually tracked in Microsoft's issue system. Microsoft Connect is the public portal to their issue system. PLEASE VOTE!

        https://connect.microsoft.com/VisualStudio/feedbackdetail/view/932051/long-filepaths-260-characters-are-not-supported

      • andrewopandrewop commented  ·   ·  Flag as inappropriate

        hello
        you are welcome
        Long Path Tool is the most appropriate program to sort out such issues

        ............................

      • 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

      • Omar RashwanOmar Rashwan commented  ·   ·  Flag as inappropriate

        It's absolutely ridiculous that I can't create a directory without running into a character limit. All other operating systems don't have this archaic restriction, especially not in this millennium. I would gladly sacrifice any features we miss out on in the time it takes to fix this bug.

      • William BosackerWilliam Bosacker commented  ·   ·  Flag as inappropriate

        @anthonyk: LPT does nothing to extend TFS or VS. LPT is a stand alone application for managing your file system. It does nothing to allow TFS or VS to access long filepaths, which is the purpose of this idea.

      • 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.

      • William BosackerWilliam Bosacker commented  ·   ·  Flag as inappropriate

        With the release of Windows XP over ten years ago, Windows has supported a file path length of 32,768 characters where each individual folder/file segment name is limited to 256 characters, and the Windows API has supported this from day 1. There is absolutely no valid reason, or excuse, that for over 10 years the .NET Framework still does not support this. The same goes for TFS, which should have supported this on it initial release.

        It would be AWESOME if you at Microsoft would pull your heads out of your ***** and fix this. Steve Ballmer is out! Who is the next person that needs to be removed to get this accomplished? Business as usual just won't cut it any longer.

      • Eric BrownEric Brown commented  ·   ·  Flag as inappropriate

        The vote count continues to climb on this suggestion. It is my hope that Microsoft will decide that simply declining this suggestion is only going to result in yet another suggestion of the same type to be created. This cycle will likely repeat itself until Microsoft decides enough is enough and dedicate development resources to correcting this ridiculous issue. Thanks!

      • Anonymous commented  ·   ·  Flag as inappropriate

        Fix this problem!
        We waste a lot of time before supposing compile errors are caused by this bound.

      • Anonymous commented  ·   ·  Flag as inappropriate

        no no.. its just the old Microsoft style of doing things.. i.e. Destroying anything useful.. and Selling the destroyed thing after some improvements..

      • AdaminkoAdaminko commented  ·   ·  Flag as inappropriate

        Have you tried using the Long Path Tool? Its sure to come in very handy in such situations.

      • Eric BrownEric Brown commented  ·   ·  Flag as inappropriate

        I was going to do the very same thing, essentially copy and paste the previous item, only I was going to add: "DON'T IGNORE US: Fix 260 character file name length limitation" for the title. :D Scott was much nicer.

      • Eric BrownEric Brown commented  ·   ·  Flag as inappropriate

        Don't just ignore the MASSIVE outcry (Just look at the # of votes on the previous link along with the rather lame excuse as to why it cant be fixed by Will Buik) Don't ignore us, Microsoft NEEDS developers to stay alive. Over 3k votes, another 810 on this one, it would be a grave mistake for you to reply with the same lame excuse.

      • Jim MichaelsJim Michaels commented  ·   ·  Flag as inappropriate

        I know of some major companies whose files went beyond that limit, and it breaks some utilities that walk dir trees, and you can't delete the files, etc. the OS is also lacking filepath length checking contraints.

      • Mart SõmermaaMart Sõmermaa commented  ·   ·  Flag as inappropriate

        The work-around is to use the \\?\ prefix as documented here: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4954037-fix-260-character-file-name-length-limitation

        The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".

      • RichardRichard commented  ·   ·  Flag as inappropriate

        Annoying limit, it just bit me now - I'm doing various Coursera courses, I need to use all kinds of oddball programming languages and packages; one fault of some of these is they seem to be limited to needing paths set at this level. So whilst I'm cursing at Oz for being old fashioned in it's setup, I find MS stuck in the stone age on this? After producing something like F# and Visual Studio? Doesn't wash guys.

      • Eli HayonEli Hayon commented  ·   ·  Flag as inappropriate

        I understand that this is a structural issue - but I have to agree with the angry mob here, this is bull - at least give us a work around? I mean there are certain cases where you cannot avoid having such a long file name. For example in the case of service references, that stuff is auto generated, I don't have any control over how long the names are. Now I cannot publish a web application because of this ridiculous limitation.

      ← Previous 1

      Feedback and Knowledge Base