プログラムから環境変数TEMPで指定されたフォルダにファイルが作れないことがわかった時点で、この問題は解決したも同じだった。TEMPの値を「%USERPROFILE%\AppData\Local\Temp」から「C:\Temp」に変更して万事解決としたが。。変更前で指定していたTempフォルダに対してなぜファイルが作れなかったか？そこを深掘りして原因追及すべし！と言い出す人間が出てこないかと今ひやひやしているところだ。
この問題長引いたのは、関わる組織が多かったことだ。アプリAがあり、そこに組み込む部品Bをおいらが作っている。部品Bには、アメリカ製のライブラリCを使っており、ライブラリCはライブラリDを使っている。Tempフォルダに作業ファイルを作っていたはライブラリDだった。別にDが悪いってわけではなくて、その事実を突き止められたのが重要なこと。初期調査の段階で、ライブラリの関数の戻り値は正常値だったので原因がさっぱりわからなかったところ、ふとしたことでコマンドプロンプトにメッセージが出ていることが判明。Error Creating Imageだったかな。標準出力にメッセージを出すprintf的な処理がライブラリCに入っていたので。おいらがCの人に報告してCの人がDの人に聞いて、その原因がTEMPフォルダにファイルが書き込めないがことが判明。Cの人はアメリカ人なので、やりとりは英語。幸いなことにAの担当者が英語が得意な人間だったので、アドバイスもらいながら、なんとかコミュニケーションがとれた。解決したぜっておいらがCの人に連絡して戻ってきた「I am Happy !」が印象に残っている。
問題の発生した状況について。エクスプローラからの操作でフォルダ参照はできるし、新規でテキストファイルを作れて編集だってできた。フォルダのプロパティからセキュリティタブを見ると、administratorsやadministrator（ログインユーザー）にフルコントロールの権限が付与されていて、拒否設定は存在せず、別になんの問題もないように見えた。ところが、プログラムからファイルを作ろうとすると失敗する。GetTempPathで取得したフォルダにCFileでファイルを書き込むシンプルなプログラムで現象が発生した。
新しいユーザーを作ったところこの問題は発生しなかった。環境変数TEMPはユーザーごとに異なるからだ。不思議なのは、その後元のユーザーであるadministratorでログインしたら一部の問題が解決したこと。普通にソフトを起動したらTempフォルダへの書き込みができて、Windowsサービス経由でソフトを動かしたら書き込めないなんて変な状況が発生。よくわからんけれども、administratorのTempフォルダが壊れたってことにして、新たにフォルダ作ってTEMPを変えることにした。
なぜTempフォルダが壊れたのかはわからない。壊れたフォルダはそのまま残してあるので、それを分析すればわかるかもしれないが、そこまでしなくてもいいだろう。今冷静になって振り返ってみると、アクセス権回りが壊れたのではないかと予想できる。アドビさんが「フォルダのアクセス権を初期化する」で触れている方法で解決したかもしれない。ようするに所有者を変更するという方法だ。今度同様のトラブルがあったときにはこれを試してみよーっと。
近頃、社内で原因分析という言葉がよく使われている。原因⇒対策⇒類似問題のつぶしこみって。なぜTempフォルダが壊れたかってことだ。そんなことは知らん。。それよりも、問題を解消するために考えて、行動して、実際に問題解消することに意味がある。何が腹立つかって、口を出すだけで行動しない人間が多いことだ。口を出すだけの人間が評価されていることだ。まぁそれもよい。口を出し続けることの苦しさだってあるのだろう。おいらはそこに魅力を感じないので、口を出さず、手を出して満足感を得たい側の人間なのだから。ともかく、Tempフォルダがなぜ壊れたかなんて知らんということだ。