IOExceptionは解析に困る。

createTempFileで、
指定したパスが見つからないIOExceptionが出たらしく、
僕もいろいろ調べたけど進展なし。

バージョン違うから参考程度だけど、
またopenjdkでcのコードを読んださ。
WinNTFileSystemのとこ。

パスが見つからないというので、
たぶんFileDescripterは関係なさそう。
Windowsで言うところのFileHandleは、
きっと大丈夫なんだろうなぁ。

ひょっとしたら8.2形式(8.3だっけ?)とかも気にしないとダメかな？
フォルダもファイル数上限なんかは見た。
WinNTFileSystemなんで、FATじゃない。
でも、もしNTFSとFAT32の混在環境だとしたら、
Javaはその辺りを賢く切り替えるのかな？
試したことないから分からないや。

もし、自分に時間とスキルがあれば、
java.ioの試験を計画したいところだ。
それくらいjava.ioの問題は解析が困難で、困ったちゃんだよ。

おいらにとって、文字コードとIOは永遠のテーマだ。
EBCDIKのエンコーダー/デコーダーを作れと言われたら、
俺はかなり没頭して作ると思う。
IBMのはCp930系統があるからいいじゃん。
日立とかのはGoogle先生も良い結果を出さないよ。
Cp930と日立EBCDIKはきっと互換してないよ。

swingは使ったことないけど、
やっぱりswingのバグももうちょい見ないとダメかも。
別のバグが起因して、
存在しないファイルパスを作ることもある。
FileChooserとかには結構な修正が出てるみたいだ。

Sun Javaのリリースノートと、
bugs.sun.comの訪問回数が増えてる。
解決に結びついたことはない。

JIS2004の話もあるので、色々なソリューションがあると思うが、
日立EBCDIKなんか使ってたら、日立から逃げられない。
IBMがオープンソースにしてるICUは、
かなりの種類の文字コードを扱えるが、
日立EBCDIKは扱えないさ。

日立の名前をあげてばかりだが、
たぶんベンダ依存EBCDIKは他にもあるはず。
IBMのは仕様がWebで見れるからいいけど、
仕様が確認出来ない文字コードなんて厄介でしかねぇよ。