Sigh! Vista still has 260 character Path limitation!

I recently discovered, the hard way, that Microsoft Vista still has a limit of a maximum 260 characters for the Path.   You can enter all the characters you probably want in [Control Panel | System | Advanced System Settings | Environment Variables | Path] but when you subsequently execute "Path" in a Windows Command Processor Console, you will see your result gets truncated at 260. 

 Worse, one day you will try to execute a command and it just won't happen,.and you may have one heck of a time figuring out why it failed.  Even worse, some sotware you run may try to execute an external dependency, under the reasonable assumption that it can be found in your path.  You're likely to have an even more difficult time diagnosing that!

How do you get a path longer than 260 characters?  Some forum trolls maintain that it's a ridiculous question and could only happen to a brain-dead Windows wimp.  Not me.  I'm senior software architect and engineer, and I try things out.  I'm always learning new technologies and experimenting with new tools.  You give me a shiny new machine with all the memory and processor you think is state of the art and I will soon have it filled up with developer goodies.  Now, if you, like me, start installing frameworks, language systems, editors, database systems, utilities, and other development tools, I guarantee you that you will soon blow past the inane 260 character limit!

So, here I am with a completely botched path.  What did I do?  I started replacing long entries with Environment Variables.  "C:\User\ProgLang\Ruby\Bin" became "%RUBY%."  You really need to be careful to put back-slashes ('\') where they need to go; a missing or extra back-slash can cause problems.

 It kind of works, and if you replace enough stuff, you may get your path to display in a console.  Unfortunately, I was not able to reduce mine enough.  Frankly, I don't consider my desired path-searchable items to be unreasonable.  I want my languages, Scala, Fantom, Ruby, Python, Scheme, Common Lisp, Groovy, etc., to be available from the command line.  I want my utilities!  I want my frameworks, my libraries!  I want all my Microsoft Visual Studios SQl Servers, SDKs and such (with their ridiculously long and space-filled pathnames!

Will your path always be useable by software?  Will it sometimes be corrupted and cause problems?  What happens when your Environment Variables get expanded?  Those questions I cannot yet answer, but you can be sure I'll be watching!

Now, let's discuss the cause.  I think it is the same old illness within the Microsoft development group that has afflicted us developers and "power users" so many times before.  Some MS-Techie decides that we'll never need more than 512K of database storage, we'll never need graphics beyond 1024x768, nobody needs more than 8 bits to represent a character.  Yeah, right!  Microsoft needs to root out this limitinitus disease once and for all and push it's devs to stop placing arbitrary and insidious bounds on those of us for which work in the real world will always exceed design parameters.  Make things expandable and extensible, please.  Stop stitching us into a corner!

Please!

 

 

3 Comments

  • I think that Windows 7 still has the same limitation as well.

  • Unfortunately, it's not simply a case of fixing Windows; there are a lot of applications out there written in unmanaged code which would break if paths were allowed to be longer than 260 characters.

    A lot of Windows APIs support long paths (up to 32768 characters) using the "\\?\" prefix [1], but unless every application is re-written to take advantage of these APIs, there's not much point using them. For example, if Windows Explorer used these APIs, it would let you move files to locations where they couldn't be opened by the associated application.

    [1] http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx#maxpath

  • This cannot change with a new operating system. It is part of the NTFS specification.

Comments have been disabled for this content.