この前、ファイルが無くなって Windowsが起動できなくなったのとは別の HDD。
最初はトレイアイコンから、ファイルが壊れてて読み取れないってメッセージが表示された。空き領域が 30GBと表示されている。最近は空き領域の確保に苦労していたので 30GBは多すぎる。
CHKDSKを試したがどういうわけか開始しない。とりあえず再起動。
問題の HDDに張っていたマウントポイントが解除されて E:\として見えている。ボリュームラベルもデフォルトに戻っている、どころか空き領域が 233GB。未フォーマットって何じゃ。どうやら、ファイルシステムが NTFS5.1だということが分からなくなった様子。
PC Inspector File Recoveryというソフトをダウンロードして試す。エクスプローラでは既に表示できなくなった、E:\ 直下に存在するはずのフォルダが表示されて何とかなりそうな雰囲気。
でも、このソフトを操作してると PCが突然再起動したりする。
さっき 4回目の再起動に遭遇した。E:\ はもう無い。
ファイルシステムがどうのという以前に HDDが HDDとして認識されなくなってしまった。
こうなるとファイルのサルベージとか考える必要もなくって、いっそ清々しいね (´Д⊂グスン
タコが熱い。軍儀のエピソードにはホロリ。
ONE PIECEは面白いんだけど「さあ泣け。さあ感動しろ」って強要されてる気がして好きになれない。ルフィの能天気さもわざとらしく感じられて嫌い。
HUNTER×HUNTERのタコとキルアの友情には素直に感動できるのにね。
第3レース終盤、ジョニィが唐突に語りだしてからジャイロとジョニィの精神的優位が入れ替わった。(着順もジョニィ > ディオ > ジャイロだし)。
最初はジャイロにくっついてレースに参加したジョニィもいつまでもジャイロの後を追うだけではないということ。
そしてジャイロも今巻で聖人の右目を手に入れたことで、最初から使えた鉄球という "特技" (技術) が強化されて (スタンド) "能力" を手に入れたけど、決して完璧超人ではないということ。
そうでないと面白くないから。
トラブル続発。
そのせいで Windows XPが起動しない。
最終的には XPのインストール CDから回復コンソールを起動して
COPY G:\I386\PCI.SY_ C:\WINDOWS\SYSTEM32\DRIVERS\pci.sys
で、起動するようになった。本当に pci.sysが見つからんかっただけなのな。
CHKDSK /R で 70くらいエラーが見つかったから HDDが原因？
DVDドライブは Q:\ に設定してたのだけどそういうのは XPが起動してから有効になるみたいで、DVDドライブが G:だと分かるまでに下のような地道な努力。
dir A: dir B: ... dir G:
結局、ダイアルアップで接続する設定になってたのが原因っぽい。
症状は 25日の夜から。
C:\Accessories\System Tools\Internet Explorer (No Add-ons).lnk のタイムスタンプが 2006/02/25/19:20。(←IE7beta2のインストール日時と思われる)
疑わしい。
Apacheサービスを HTTPDアカウント(Usersグループ)で走らせるようになってから、sqlite3.dllを使う、Rubyで書かれた CGIスクリプトが「logic error or missiing database」を出すようになった。
エラーを直接投げてるのは Rubyのライブラリの sqlite3-rubyだけど、エラーメッセージは SQLiteのライブラリ(sqlite3.dll)に由来している。
エラーを出す原因となった SQLは以下。
SELECT * FROM sqlite_master WHERE type='table' OR type='view' ORDER BY name;
データベース内のテーブルとビューの一覧を取り出すためのありふれた SQL文。
問題をややこしくしたのは
SELECT * FROM sqlite_master WHERE type='table' ORDER BY name;
だとか
SELECT * FROM sqlite_master WHERE type='view';
でも同じエラーが出るのに
SELECT * FROM sqlite_master WHERE type='table';
だとエラーが出なかったこと。
結論から言うと SQL文は悪くない。
Apacheを SYSTEMアカウントで動かすとエラーが出なくなったので、Apache(と Apacheが CGIとして起動する Ruby)が HTTPDアカウント(Usersグループ)で動いてることに原因があると考えた。それなら書き込み権限がないせいでエラーになってるのかもしれない。
データベースファイルやデータベースファイルを入れるディレクトリには当然 HTTPDに対して書き込み権限を付けてある。
SysInternalsの FileMonを使って確認したところ、ruby.exeが C:\WINDOWS\sqlite_XXXXXX(文字化け) を CREATEしようとして Denyされている。
sqlite-3.3.4の os_win.cに
char *sqlite3WinFullPathname(const char *zRelative)
という関数があり、Cygwinや WINCE以外の WINDOWSプラットフォームではそこから
GetFullPathNameW/A
という APIが呼ばれている。おそらくこの APIが "C:\WINDOWS\sqlite_XXXXXXX" というパスの出所だろう。
ここをいじって
"%TEMP%\sqlite_XXXXXXX" => "%USERPROFILE%\Local Settings\Temp\sqlite_XXXXXXX => "C:\Documents and Settings\HTTPD\Local Settings\Temp\sqlite_XXXXXXX"
上のような Tempディレクトリにファイルを作成するようにするのもアリだろうが、そういう変更をすると SQLiteのバージョンアップに追従するのが面倒になるので Rubyスクリプトの方で対処する。
sqlite3-rubyでは
db = SQLite3::Database.new('hoge.db');
db.temp_store = 2; # 2=memory, 1=file
SQLでなら
PRAGMA temp_store = MEMORY;
(参照) Pragma statements supported by SQLite
SQLの方は試してないけど、sqlite3-rubyの方で対処したところエラーが出なくなった。
エラーメッセージが的外れなのでここまで来るのに苦労した。
PRAGMA temp_store_directory;
PRAGMA temp_store_directory = 'directory-name';
Query or change the setting of the "temp_store_directory" - the directory where files used for storing temporary tables and indices are kept. This setting lasts for the duration of the current connection only and resets to its default value for each new connection opened.
When the temp_store_directory setting is changed, all existing temporary tables, indices, triggers, and viewers are immediately deleted. In practice, temp_store_directory should be set immediately after the database is opened.
The value directory-name should be enclosed in single quotes. To revert the directory to the default, set the directory-name to an empty string, e.g., PRAGMA temp_store_directory = ''. An error is raised if directory-name is not found or is not writable.
The default directory for temporary files depends on the OS. For Unix/Linux/OSX, the default is the is the first writable directory found in the list of: /var/tmp, /usr/tmp, /tmp, and current-directory. For Windows NT, the default directory is determined by Windows, generally C:\Documents and Settings\user-name\Local Settings\Temp\. Temporary files created by SQLite are unlinked immediately after opening, so that the operating system can automatically delete the files when the SQLite process exits. Thus, temporary files are not normally visible through ls or dir commands.
%TEMP%フォルダでなく %WINDIR%にテンポラリファイルを作ろうとするのは Windowsのせい？俺のせいでした。
httpd.confに次の行を加えるべし。
PassEnv TEMP
確かに、確かに萌えが存在している。ギャップだとか弱点に萌えが宿るのは真実。何かのインタビューで桜庭さんが仰っていた通りです。
http://www5a.biglobe.ne.jp/~dai_/diary/diary0602.htm#05 (DAIさん帝国)
標準シールドの詳細な設定に「新規作成/修正されたファイルを検査」という項目がある。
これにチェックを入れて、さらにその下のラジオボタンで すべてのファイルを対象にしたとしても、ウィルスファイルが作成されるのを検知できないことがある。
こういう状況で C:\Data Files\HOGE.ZIP を解凍(エクスプローラの「全て展開」を使用)して、C:\Data Files\HOGE\VIRUS.FILE というウィルスファイルが作成されても Avastは検知しない。
比較のために C:\Documents and Settings\UserName\デスクトップ\HOGE.ZIP を解凍してみたが、これは検知した。
さらに試すと、Data Files\HOGE.ZIP の展開先をデスクトップにした場合、Avastはウィルスを検知するが、逆に デスクトップ\HOGE.ZIP を Data Filesに展開した場合はウィルスを検知できない。
総合すると、別の HDDがマウントされているフォルダの下にウィルスファイルが作成されても Avastは検知できない。
違った。この HDDに Zドライブを割り当てて C:\...\デスクトップ\HOGE.ZIPを Z:\HOGE\VIRUS.FILE に解凍してみても検知しなかった。Cドライブから、同じ HDD上の違うパーティションである Dドライブに解凍したら検知した。
結局のところ、ウィルスファイルの解凍先がパーティションをまたいでいたとしても同じ HDD内なら検知するが、解凍先が違う HDDのときは検知しない。それとは別に、解凍先が、別の HDDが割り当てられたフォルダ*の下であった場合は、ウィルスの入った ZIPファイルとその解凍先が同じ HDDであろうがなかろうが検知しない。
* `dir`によると<DIR>ではなく<JUNCTION>