It's MAX_PATH in Windows (== 260. There's a 32K Unicode-equivalent limit[1]). In Linux it's PATH_MAX, which is (very likely) 4096. That's a bigger number than 260, sure; but it's still a discrete one; instead of, say, ∞.

---

[1] 'To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".' http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...

Visual Studio (at least 2010 and 2012) also has this problem, actually. If the path (including filename) to your solution file is more than 218 characters, it refuses to work with it.

Welcome to 1995!

My favorite experience with it was trying to deal with a zip file of "C:\Documents and Settings\" from an old computer that happened to contain multiple files whose paths were 255 characters long or so. You couldn't unzip it in a subdirectory of "C:\" because one of the resulting paths would be too long and cause the built-in zip program to crash/fail entirely. Using 7zip was the eventual solution.

On a related topic, do you know how difficult it is to search for files whose path are above a certain length on a fresh/default Windows setup? I eventually resorted to installing Python on it just to write a script to do it.

MAX_PATH, bane of my existence. I cannot count the times a customer did not find a document in search because Windows decided to throw this limit in our faces. It can pop up at the weirdest places ...

I'm pretty sure I said this exact same thing when my boss finally figured out that this issue was causing a script we use to fail on the BOMs I was trying to release. It took an embarrassing amount of time for a few engineers to figure that one out.