Filesystem Paths: How Long is Too Long?

The key area where the MAX_PATH limitation becomes a major problem is for applications that use the file system as a database (which is an entirely reasonable thing to do). In this case, the hierarchy is not something the end user directly controls or interacts with, but in this day and age an application should be able to have pretty much an arbitrary hierarchy depth without having to deal with API hacks.

MAX_PATH is an ugly API wart that we may have to live with for a long time due to backwards compatibility (which is important, too).

Here’s the final version for Powershell which searches all drives:

gdr -p FileSystem|%{gci -r -fo $.root}|%{$m=0}{$f=$.fullname;if($f.length -gt $m){$n=$f;$m=$f.length}};$n

It will print some errors on unmounted usb and cd/dvd drives but it works great.

Still courtesy of “dreeschkind” on the powershell ng.

When i use this powershell, i get error messages when the path is too long, but it doesent show which are too long.

Is it possible?


The main reason MAX_PATH is 260 is because a lot of developers are goddam idiots who genuinely think (to this day) that using a #define PATH_LENGTH 256 at the top of their projects is a WONDERFUL idea. After all, 256 is a nice round number in binary, and who in their right mind would ever use more than 256 characters in a path? Doesn’t (random tweak site) say paths are limited to 256?

Until the application dies from a buffer overflow as soon as it tries to open that file that’s 257 characters long.

Mac and unix apps are not immune from this! After all, there are idiots writing software for any system. I’ve seen it happen occasionally (rarely, who deals with paths that long every day?), and I’ve seen it in code, open source and otherwise, more often than I can count. An OS feature that crashes half the software on it as soon as they come across the feature isn’t an automatically great idea.

(btw, there are fully native win32 ports of unix tools, no cygwin required, as well as win32 variants of common unix functionality. Not sure why any unix guru wouldn’t have them otherwise, unless they hadn’t been forced to use windows for any reason since NT was hot.)

I ran into a similar problem with one of our source trees the other day when I tried to copy it to a build directory that had a few more characters. I wrote a similar app, but one thing I added was a count of how many dir/files were of each length 1-300char.

At least on my system with a lot of hidden by the OS stuff in local settings, and .net stuff I have hundreds of paths that are over 200, and plenty in the 240+ range.

Can you refactor for smaller paths, sure, is that always the right idea. absolutely not. sometimes a descriptive hierarchy is a good thing.

For most UN*X users a quick

/ # find . | wc -L

should do the trick. You just gotta love a unixish environment after comparing the one-liner to the C# code :wink:

Jan-Erik: I’m afraid I don’t know Powershell well enough but the command only prints the longest path, since the max limit is in the api I would assume powershell hits the same limits.

I think you can probably catch the error but I can’t provide an example.

sigi: What is it that is so hard to understand that he chosed to make a program of this ? The post wasn’t about “one liners” although I showed this can be done as a one liner with Windows Powershell as well.

Would the C/C++/C#(yes it’s possible) program on nix be smaller ?

So I was using Powershell to check for a long path on one of our network drives, but alas:

Get-ChildItem : The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

Why does Shell blog say that MAX_PATH includes the terminating null to contradict MSDN, which says it includes the terminating NULL? Dude you gotta read between the lines!

@KL: “I would argue that with Windows Powershell the most powerful command line is actually on Windows these days. […] Unfortunately I havent had tim to learn powershell yet.”

ROFL. Funniest comment in the thread. Please wiki hypocrite chap.

2 cents. No matter if it was a *nix or windows or whatever, 260 character paths are reminiscent of ‘640k is enough memory’. It’s a ridiculously low value. Maybe vista compatibility should have been done with an abstraction layer so that old crap API’s could be done away with for good. Old programs - old api. New programs - new api. Short term pain means long term gain for Vista because old the programs will still need updating regardless.

We should treat the file system as a database and realise that we need more than just filename + path. I like descriptive names and directories, but properties-Advanced is far too kludgy and i can’t convince my mom to do it. She for some reason likes to call files things by meaningful names. consider
’/documents and settings/mom/my documents/letters/personal/2005/medical/knee problems/the letter i sent to dr spock about tenderness after vermont ski trip’
or better yet

I don’t think hierarchies are dead, nor will they ever be - until world robot domination that is - 'cause our robot masters don’t need them.

At least we have google desktop.

Dr 1.0: learn it and you’ll be suprised, it contains way more powerful features since you can manipulate any object on the system and the whole .net framework from the command line.

Can you do that with bash ?

In any case, this discussion is old, only the trolls left and people like me that jsut has to answer the trolls.

The limit is there because of compatibility, end of story, I guess if longer file paths is all you ask from a system then by all means use nix system.

The easiest thing to do is to do is to make a filename only so long, and then use metadata to store the rest (can metadata be applied to folders?). Of course, you could just get a real OS… like SuSE Linux.

Yes he does, it’s called the Windows Powershell

Maximum path lengths turn the file system into a
leaky abstraction

totally agree. if the user is given enough rope to hang themselves by other systems, then newer system shouldn’t break on it.

let’s not be presumptuous.

oh, 256 as a limit is just arbitrary and wrong, don’t get me started. but no, i’d never use that much.

“And looking ahead, if you notice my system headers are versioned – OS X can retain the old libraries each time it is updated, so future upgrades won’t be an issue with breaking older apps.”

Windows also supports this, it’s called side by side execution.

Wanting 32,000 character paths isn’t about usability; it’s about breaking getting rid of a bothersome, low-visibility, programmer assumption.

I really don’t know of a programmer that gives a lot of thought about path lengths until the end of the project (if even then). When talking about an apps “future compatability” this isn’t something that comes up. If the client wants to organize a massively long and tangled heirarchy of data, we’ll just tell tech support to say “Don’t do that” when they call for help. We may blame the user for the problem, but fundamentally it’s our assumption that this is a non-issue.

While 256 character path lengths are far more than I’ll ever need in my work, API’s that supported 32,000 character length paths throughout would completely remove any worry about that assumption from my mind.

I ran
"gdr -p FileSystem|%{gci -r -fo $.root}|%{$m=0}{$f=$.fullname;if($f.length -gt $m){$n=$f;$m=$f.length}};$n"
and it turned up
"D:\Library bringhomes\1\files\Google Image Result for http–www_zdnet_co_uk-i-z-rv-2006-09-vista-rc1-i6_jpg_files\0,390
which is 259 characters (counted with VB 1.0). Thanks for reminding me that that folder exists! (My 'net access used to be at our library. I would bring stuff home to look at later - especially webpages, some of the navigation systems in websites are sooo coool.

I must comment about Windows Powershell. Finally Windows can teach me that ‘cd’ won’t work anymore and I have to do ‘cd /’. However, I am what one might call a UI designer-graphic designer-programmer multi so I like to see that an interface is well written and works well, so I like things to, well, look nice. Upon downloading and installing this “PowerShell” (and the .NET framework) I immediately right-clicked the titlebar and hit ‘Defaults’. No matter what I changed I could not get 80 lines, Lucida Console and all that changed. It defaults to the BSOD blue for the background and the ‘DOS white’ for the foreground. I don’t know if PowerShell will replace CMD or if it will be just a tool.

By the way, if anyone actually does find a way to change PowerShell’s settings then post or mail dav7[at]bigpond[dot]com.

I mentioned VB 1.0 before. THAT was one VERY GOOD programming language. 564KB, nothing else (really) required! It would fit on a floppy! You don’t have to try and be Mr. 10 Diplomas to write something in VB 1.0 (very much unlike VB Express!). Did I mention the fact that the single “dependancy” was only 264KB (I think)? That was the age when code and UI equally mattered and people paid attention to detail.
Unlike today…

In my last post I mentioned whether PowerShell would replace CMD or if it would be a tool. I forgot to explain that I meant that if PowerShell wasn’t customizable then the chances are that I wouldn’t enjoy using it and would have to go back to CMD (the standard Windows commandline).

The single dependancy was indeed 264KB and was named VBRUN100.DLL. I find it very fascinating that you actually don’t find this file included with ANY Windows version (even Win95 98).

I wonder if good old DOS with the long names converted to 8.3 format hits that limit as well. I mean: would it be possible to copy a file to a 259 char path when you reduce it to its 8.3 format.

So instead of trying to copy a file with XP to:

C:\Documents and Settings\Some really long and overly complex path that is no use to anyone whatsoever etc etc etc until the 259th character\

use DOS to copy to:

Hmmm gonna try that when I find some time between typing replies to blog entries like these …