Windows file path FAIL

I'm going to take a break on testability to talk about file paths - specifically long file paths, and the care one must take when dealing with them on Windows.

Now, while quite a lot of technologies are involved in development, for me (right now), the most important to mention when dealing with files are: Java, Subversion, Windows, and Tortoise SVN. I'll throw in one more - the filesystem (NTFS).

Using the command line is part of my nature, so when I get into the office in the morning one of the first things I do is open up a command prompt and 'svn update' my working copy.

Imagine my surprise one day when I couldn't update, because Subversion claimed one of its .svn/... files was corrupt or missing. Cleanup didn't help - it wasn't actually a Subversion problem. It was a file path problem. The svn FAQ actually has great information on this.

Enter the windows API maxium file path limitation of 260 characters. What's annoying is that it isn't ALWAYS the limit, in fact the unicode version of the API has a much more flexible limit (thousands of characters). Why then, does Windows Explorer, even in Windows 7, still use the API that has the 260 character limit? *

I deal with this issue again and again. I generally don't create file paths this long, but it doesn't matter - because I work as part of a team. I think it's reasonable for people to have descriptive, rich naming for their stuff - I just wish it wasn't so painful. Once files are in version control, then build tools, installers, and all kinds of things MIGHT have an issue depending on where the files are checked out and what file API they use. It's just not an issue I should have to deal with.

I don't want to worry about long file paths - this is a simple request. Of course, simple problems for computers aren't always simple. In fact, they usually aren't, but the fact that the API exists but that it isn't already the defacto, default API used by Windows itself frustrates me.

I want to be clear - this isn't a limitation of NTFS, Java, or Subversion. They are all quite happy to deal with long filepaths. It's the Windows file API. It's just easier than normal to get into bad situations when you have tools that will very happily (as they should!) create and deal with long filepaths, only to have your operating system tell you the file doesn't exist or can't be accessed.

* Probably backwards compatibility

That's my rant for the day.

Java path mystery...solved

For ages, I've wondered how in most cases, java will mysteriously be in your path in windows, even though there is no Java install directory in the path. (it will certainly be a version that was installed with a proper installer, at some prior point, but not necessarily the most recent version you've installed) To fix this, I generally put %JAVA_HOME%\bin; at the front of my PATH environment variable after defining JAVA_HOME to point to the Java install I care about (something Ant, Maven, and other dev tools often care about having defined...).

I've always wished I had the 'which' command in Windows, so I could locate which Java executable was in the path. Finally, by chance, a coworker was debugging an OpenGL crash with an Intel GMA graphics card and substituting DLLs in what he thought was the 'run' directory, and he realized that it wasn't picking it up when he put it in the directory of the JDK bin he thought it was using... When he checked process explorer, lo and behold... C:\WINDOWS\SYSTEM32\java.exe is what was running. What the heck??? I find this strange, yet there it is.

I have always thought it was registry magic, or some other trick that caused Java to end up in the system path unless you put it as the FIRST path entry. Instead, FIRST just means AHEAD of the System32 folder. (Several apps likely to be in a dev environment often put themselves at the front of the path, subversion, oracle, etc...so I never noticed that the usual first entry in the PATH is this...and I typically put entries at the END of the path except when I know there will be other entries fighting for this position)

It's funny how sometimes mysteries like this go on for many years - maybe it's a simple Eclipse feature nobody knows about, or some maven quirk, that we never take the time to fully investigate and understand...we just come up with the rule and follow it - at least it's what I've observed.

If anyone can shed some light on this, I'd love to hear it. Is this practice generally acceptable to pollute the SYSTEM32 folder with executables? For now, I am satisfied to now know why I need to put my java/bin at the front of my path...