Thursday, November 5, 2009

Problem with path longer than 260 characters


Thomas Lee wrote about some issues they are experiencing with Get-ChildItem in this excellent blog post – to make long story short, Powershell is limited by underlying .NET architecture. Thomas mentions mostly performance issues – however I don’t really care about performance as long as it is stable and reliable.

My biggest problem is with path limitation – event though NTFS itself supports paths up to 32.000 characters.

This is error message you get from Explorer when you try to specify longer path:


Very nice blog article about this problem can be found at Coding Horror. Eamon Nerbonne had some nice comments about this problem also.

Why is it so irritating? Almost everyone I mentioned this problem I received answer like “If you run into this problem, it’s your fault, because your are using too long folder\file names”. Shouldn’t 260 characters be enough for everyone?

I don’t think so. First, I don’t see any reason why people shouldn’t use deep structures if they prefer it. I don’t – but that doesn’t mean that everyone had to use same style of work as I do.

That applies to others, but doesn’t describe where is my problem with such limitation. I am mostly focused on enterprise customers – when you implement enterprise solutions, you cannot simply build something, but you must follow some guidelines, like naming conventions. Naming conventions usually apply to all departments – and more people or departments are involved, more complicated they get. If you store your files at network share, their name is also included in that limitation. Let’s consider that our fictional company called “Microsoft” will have development trusted domain. In that case, you can access it using following syntax:


On this network share, we store our installation sources. First of course we categorize them, because we got hundreds of applications:


Ok, so we got installation sources from Office 2007 – because there are multiple editions, we will use iso name as folder name:


And that’s it. So our final path is


If we could it together, we are at 101 characters already. Add longest file (\Proofing.en-us\Proof.en\ and we are at 135 characters.

Ok, that’s not that bad, isn’t it? Well, it is. With very basic categorization (no platform, no departments, no versioning etc…), we already reached 50% of the filesystem limit. And don’t forget that Office is VERY flat installation package compared to others (like XenApp for example).

If we have a look at another example, we can use Application Compatibility Toolkit. Longest file name is 174 characters – already after 50%:

"c:\Program Files (x86)\Microsoft Application Compatibility Toolkit 5\Internet Explorer Compatibility Test Tool\Agent Framework\Agents\Bucketizer\BktOutputReverseTransform.xsl"

If we would like to copy it to our sources (\\\CTX_D_Sources$\Admin\Microsoft Application Compatibility Toolkit 5\Internet Explorer Compatibility Test Tool\Agent Framework\Agents\Bucketizer\BktOutputReverseTransform.xsl), we are already at 214 characters (so almost over the limit).


Anonymous said...

Windows 7 - more than 10 years since Windows 98. Longest path still at 260 characters. What an epic fail.

Martin Zugec said...

Biggest problem for me is that it IS possible to create longer path with some tools...

Either (at least) explorer, .NET and cmd should support longer paths, or it should be forbidden for everyone.

Now it is very messy, because you can easily get to situation where you will create file\folder that won't be accessible even though it exists :(

Unknown said...

Thanks for your post and welcome to check: here

webdesign said...

it is good

AdamGrat said...

i have same problem.Long path tool worked perfect for me.Visit the following site for details Please

Unknown said...

Long path tool is the best solution for your problem. try it and solve your problem.

Unknown said...

Here's a permanent solution for MAX_PATH:

Import-Module [path-to-AlphaFS.dll]

# Remove folder, subdirectories and files.
[Alphaleonis.Win32.Filesystem.Directory]::Delete($path, $True)

joshua42 said...

I would recommend in this case to try program Long Path Tool

Rogerson said...

Long Path Fixer presents you with a simple list of files and folders in the current directory (including “hidden” files and folders). You can drag and drop files or folders onto it and it will navigate directly to path of whatever you dropped.