読者です 読者をやめる 読者になる 読者になる

きどたかのブログ

いつか誰かがこのブログからトラブルを解決しますように。

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で見れるからいいけど、
仕様が確認出来ない文字コードなんて厄介でしかねぇよ。