The sins of our fathers

"Fathers shall not be put to death for their sons, nor shall sons be put to death for their fathers; everyone shall be put to death for his own sin." (Deuteronomy 24:16) But, of course, we are paying for our fathers sins. Not so much our biological fathers or ancestors, but our predecessors. In my case, this is what's happened today: I wrote a very small Java program that extracts the Linux Kernel sources (More on the reasons and background, hopefully, in my next posting. Suffice it for now, that I'm not rewriting "tar xzf". I'm not that stupid! I had a good reasons. Now, the Kernel Sources are containing in particular, a small file named "aux.c". And my own program threw a FileNotFoundException when creating that file. Reproducible! The error message was, of course, meaningless, so I began to start thining about all kinds of reasons:

1. Permissions, either those of the file itself, or the containing directory. Mo, the permissions were just fine!
2. Length of the path name. Actually, the full path name contained quite some characters, but still far away from the 256 that I am aware of.
3. Too many open files. No, I have had my share of beginners faults and was properly closing.

Any other ideas. I guess you don't get this one: Some JDK programmer was actually implementing a check for aux.*, nul.*, prt.* etc when creating a file, because these file names where in fact a problem with Windows in the past. Of course, the sensible solution would have been:

1. Wait for the error message from Windows.
2. Check the file name.
3. Throw a meaningful error message that explains the problem.

That way, veything would have worked fine, if the unthinkable happened: Windows eliminates that stsupid restriction. Because that was exactly what happened. There is now problem with creating that file. Convince yourself:

  $ touch aux.c

  jwi@MCJWI01 /c/Users/jwi/workspace/afw-vfs
  $ ls -al aux.c
  -rw-r--r--+ 1 jwi Domain Users 0 May  1 16:02 aux.c

  jwi@MCJWI01 /c/Users/jwi/workspace/afw-vfs

So, our JDK programmer has managed to move the problem with the "aux.c" file name from Windows to the JDK. Thanks, a lot!