a companion discussion area for blog.codinghorror.com

Filesystem Paths: How Long is Too Long?


I think this depends on your perspective. If you follow Microsoft’s lead by plopping your source code into \Document and Settings\UserName\My Document\Visual Studio 2005\Projects, you immediately lose 72 or so characters from MAX_PATH. If you also follow Microsoft’s lead by naming your projects Company.Product.Project, you lose another long length from MAX_PATH.

If you want to solidify the issue, drop Microsoft’s Enterprise Library source into the Visual Studio 2005\Projects folder and count again. You’ll find the path length well exceeds the 260-character limit, Visual Studio can’t compile the project, and SyncToy can’t synchronize the project folder to offline storage.


My post was not intended to be a Windows flame.


Well, some open source systems like Hipergate have a Corporate Library system based on subdirectories, and they have a nice way of naming diretories, something like mydir~00001, of course you can see paths like

the “c0a801bf10080e106af1000009cb90d5” is the owner’s primary key of the document, well whit 4 or 5 levels of Hierarchy plus the file’s name you have a big problem, is very common have troubles with six months to one year of use.


No need for a war between Unix and Windows: Moon’s oneliner works on cygwin.


Many years ago I tried to teach a non-computer user about trees and folders. Since they had never had the pleasure of using DOS commands like “cd” and typing lots of filepaths, it was hard.

But, there is the temptation to mingle the concepts of “how much filename and pathname do I reasonably need” with “how many levels of hierarchy actually make sense?”. 15 levels of 20-character filepaths will apparently break things. Is this unreasonable? Is it retarded to do this?

Trees and folders force a physical hierarchy, and like any man-made system this has its pros and cons. Would allowing 5000 character path names make a better world? Probably not, but situations such as foisted on Jeff by his customer certainly make you wish for a few more than 259.


The path limitation has bitten me a number of times, usually because of generated paths. For example, Oracle’s “Workspace Drive” client (basically a WebDav-based IFS) creates cache directories constructed from the local cache directory plus the remote directory path.

The local cache directory is placed in the Microsoft-approved location (“C:\Documents and Settings%username%\Application Data\Oracle\ODrive\cache”), which chews up about 80 characters. The server portion of the path (with the fully-qualified server domain name and a few directories to get to the share) chews up another another 50 or so. Then a somewhat-deep directory structure, which was perfectly valid when it was created on the original SMB-shared server, pushed the path length over 260 characters.

The odd thing was that the Oracle client had no trouble creating these directories (probably using the UNC trick you mention), but when I tried to upgrade the client and the installer choked when it tried to delete the old cache directories.

In the end, I had to resort to the old SUBST.EXE utility to map a drive halfway down the long path, delete everything from that mapped drive, then unmap the drive and delete the rest before I could upgrade.

So no–in the age of mechanically-generated paths, 260 characters isn’t enough for everybody.


I’ve recently come across this with a bug report on some code that I’m working on, and it sucks, big time.

First, the wonky unicode workaround does not work in .NET. Period. The max filename limit for .NET 2.0, a proper 21st century programming framework released in 2005, is 260 chars.

Second, on XP, the path for user documents belonging to a certain type of application is:

c:\documents and settings\username\my documents\application projects\

which is about 70 chars. Worse, on some of our users systems, they have:

\server\users\department\documents and settings\username\my documents\application projects\

which is almost 100.

From there, projects are saved in their own directory with the name given to a project. For the projects our users have, they generally include stuff like the name of their client, the year and month of the project, and a meaningful description of the project in the project name. e.g.:

MegaCorp contract for frobbing the gromits - Sep 2006

There’s another 50+ characters there. Project names of 80 characters aren’t /that/ rare and project names of 120 characters exist.

That’s over 200 characters. Now we have files in that directory and some subfolders. Users create files with meaningful names too.

You can hit that 260 char limit pretty darn quick. But the only thing we can tell our users is not to use nice long descriptive names for things, despite the fact that Windows is supposed to support long filenames.


Thanks to Moon’s script, here’s mine:

300 /Users/carlmanaster/Music/iTunes/iTunes Music/Coviello, d’Intino, Matteuzzi, Ricciarelli _ Gelmetti - Orchestra della RAI di Torino/Rossini_ La Gazza Ladra - Milan 1817 - Pessaro 1989 (Disc 2)/2-06 Stringhe e ferri da calzette; Ecco la gabbia; Andiam tosto; Eccovi, omiei signori; E sopra e sotto.m4a

Which I’ve got to acknowledge is a fairly long filename, but I didn’t do anything elaborate to create it. I’m not a fan of using filenames to store database information, but obviously some people are.


All hierarchical file systems are dead-ends. That includes blessed *nix and all flavors (with whatever limits) derived from it. Programmers apparently live in a world of infinite play time. Real people just want their documents. This is the last hardware hurdle we must cross: the limitations of physical IO. Once storage has no moving parts hierarchical file systems will go the way of the dinosaur.


Maximum path length is a horrible joke. It is unbelievable that MS can’t fix this after so many years, and that the author of this blog accept this stupidity as a good thing.

I guess the next post will be how the various invalid characters in Windows file system are not really needed and actually a great idea :slight_smile:


Here’s a one liner for Windows Powershell:

ls -r C:|sort {$_.fullname.length}|select -l 1|select fullname

Thanks to “dreeschkind” on the microsoft.public.windows.powershell newsgroup.


Without wrapping the result:
ls -r -fo C:|sort {$_.fullname.length}|select -l 1|select fullname|fl

The longest path I have is
C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\Business Intelligence Wizards\LanguageProjects\JSharp\JSharpDWWizards\ADOMDStoredProcedure\Templates\1033\assemblyinfo.jsl

Which is 202 characters.


At last, *nix vs. Windows condenses to actually slapping them on a table and getting a ruler. Why did it take this long?


Since when the linux version matters for a program to work? As far I’m concerned it depends on the libs used to build the program. So you can build software in a new version of a linux distro and it will run on an older version. So I don’t know what your talking about.



Si: I just wanted to show that this is entirely possible to do on a “one liner” in powershell.

An argument you often hear from the nix people is how powerful their shell is, we’ll, I would argue that with Windows Powershell the most powerful command line is actually on Windows these days.

But those commands are not from me but courtesy of “dreeschkind” on the powershell ng. Unfortunately I havent had tim to learn powershell yet.


The Maximum path is a serious limitation of the dotnet framework. I was flabergasted when I first encountered the problem with a scanning tool I wrote. 99% of the time, it is not an issue, but one application routinely makes files that exceed this limitation …

Internet Explorer.

It’s cache files tend to be long enough that I cannot access it’s files using the dotnet framework - I end up calling the API directly with the \?\ nomenclature to get a file handle, and then use that handle toaccess the file… a big pain in the *.

The only files I have encountered larger than the limit are created by MS programs, although a new network folder naming policy at my workplace is sure to change that
\some_server\some_device\OrgUnit\OrgUnit\Division - Office\Folder Name - Person Responsible For Content\SubFolder - Person Responsible For Content\etc


I’ve run up against this a number of times when I was working with InstallShield. They create a large amount of folders on their projects - all with nice, long descriptive names.

Because of this, instead of saving them in the traditional “Microsoft approved” place of C:\Documents and Settings… I had to save them in a folder directly on the root directory of C.


KL – way to go with that Powershell script.

I ran Moon’s script on a Fedora Core 6 system, and found that (i) the longest path was shorter than any other OS reported yet, and (ii) it’s a file from .net!

144 /usr/lib/mono/gac/System.Runtime.Serialization.Formatters.Soap/1.0.5000.0__b03f5f7f11d50a3a/System.Runtime.Serialization.Formatters.Soap.dll.mdb


To Anonymous: You noticed that too?

To Jeff: WTF? (Why the flip?) Glad to see you on the Dark Side…

To all the Win/Nix combatants: Whatever gets the job done. If one tool doesn’t work, get the right one. When the tool doesn’t work, don’t bash it 'til it’s dead cuz it aint gonna die. Someone else will pick up that tool and use it perfectly for their purpose. Just cuz it didn’t work for you doesn’t mean it won’t work for someone else.

I’ve used Mac in the past. It worked for what I was doing. I’ve used Linux (still do) and it works for what I was trying to do. I’ve used Windows DAILY since Win 3.0 and it does what I need it to do.

It’s what I preach to my son (and my wife sometimes…) use the right tool for the job.

The same goes to all you VB vs. C# vs. C++ vs. [insert programming language here]. It’s just a tool. I’ve used a lot of them in varying degrees. Each has its own little niche that accomplishes a task. Use what suits the task.

To all in the USA: Have a great holiday weekend!


Using the Powershell cmd, this one is 248 characters long:
C:\Temp\OldPC\PROJECTS\PIVOTAL\TEST\Documentation\6 - IPG Retail\08 Training\IPG Leasing System - Retail\Documentation\Retail Final\Property Management\Training Presentation - Prop Mgmt and Operations Getting Started_Contact_Opportunity_Mgmt(1).ppt