Hacker News Reader

Comment by nawitus | Hacker News Reader

I wonder if it can handle paths with more than 254 characters.

...but, why would you need it?

Once your path gets longer, aren't your essentially just stuffing your file name with metadata which should belong in the file in the first place?

Wow, surprised at -4 downvotes. Handling long paths is necessary when working with Node.js, for example.

ReFS can. http://en.wikipedia.org/wiki/ReFS

So can NTFS. In fact, you've been able to create paths with up to 32k-character file names per node since Windows NT 3.1. This is even available from Win32, and has been for a very long time: simply prefix your path with \\?\ and you're good to go.

The issue is that Explorer--and by extension, virtually every Open/Save dialog in every application--cannot handle paths longer than 254 UTF-16 bytes. I'm fairly sure at this point that Microsoft does that purely because they're not sure application programs can handle paths longer than 254 UTF-16 bytes (and they're likely correct), so they're trying to prevent users from making files that they can't open, but I find the entire situation absolutely infuriating. (In fact, as a Windows dev, it's really just that and the inability to delete open files that drive me bonkers on a regular basis at this point. Most of the rest I either like or have good workarounds for.)

C programmers (including me when I'm lazy) will often simply allocate MAX_PATH characters for a file name buffer and not think about it.

Exactly; that's the problem. The usual correct way in Windows of calling the function with `NULL` to get the length, then allocating the buffer and passing it back in, is wicked annoying with path names, so most developers simply don't bother.

Interestingly, while that problem doesn't exist in .NET, and so you'd think that .NET would finally support long file names by default, Microsoft actually goes entirely the opposite direction: the BCL strips out any leading `\\?\` in paths to force you to stay at MAX_PATH or below. The more things change...

You know there's a way around having to do those things every time you use CreateFile, right? It's a neat thing they invented many moons ago, starts with an F and ends with "nction".

Which leads to an ever-growing file called "Utilities.cpp" that gets copied into every C++ project you ever write and god forbid there's ever a bug fix you have to do because it now needs to be applied to 20 separate projects in 20 separate version control systems.

There are ways around having to apply a patch 20 times, too. Libraries and git submodules to name a few.

Secondly, if you use 20 version control systems, you're doing it horribly, horribly wrong.

Reply on news.ycombinator.com