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:

\\CZPRGHOS1DV15.development.microsoft.com\CTX_D_Sources$

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

\Office

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

\EN_Office_Ultimate_2007_DVD_X12-22244

And that’s it. So our final path is

\\CZPRGHOS1DV15.development.microsoft.com\CTX_D_Sources$\Office\EN_Office_Ultimate_2007_DVD_X12-22244

If we could it together, we are at 101 characters already. Add longest file (\Proofing.en-us\Proof.en\Proof.cab) 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 (\\CZPRGHOS1DV15.development.microsoft.com\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).