つぶねこ

　待避していたデータを呼びたくて、RATOCにHDDを入れる。
　普通に使えていたが、にゃんだか調子がおかしくにゃる。ここいらの記憶は曖昧だが、普通に読めていたドライブにファイルを書き込もうとしたら、ドライブが変とか言われて書き込めにゃかった。で、このメッセージをいつもの権限関係だろうと無視して、ACLを見に行ってたら、アクセスそのものが蹴られるようににゃって、ハード障害だと見にゃしてRATOCから引っこ抜いたのである。
　他のUSB外付けに繋げてみたら、PCからのアクセスがある度にモーター回転がリセットされる。冷やしたりにゃだめたりさすったりしたがいまいち症状が変わらにゃい。
　これはドライブが死んだかと思うも、どうも挙動が腑に落ちにゃいので、再度RATOCに放り込んで、しつこくアクセス。RATOCからはドライブがリセットされているようにゃ音は聞こえにゃい。ここいらはアクセス時の方法が異にゃるのか、特定箇所を読みに行かにゃいからにゃのかよく分からにゃいが、とりあえずディスクダンプは取れるかもしれにゃい。
　まずはFile Recoveryでscanさせるも、何も引っかからにゃい。弱いにゃぁ。
　で、ここにきてchkdskをかけるとぎりぎりドライブとして判断してくれたらしく、NTFSの強烈にゃ状態復元が始まる。ていうか今までディスクに書き込んだつもりはにゃいんだが、にゃんでドライブとして認識するようににゃったかにゃ？とか思いつつ、chkdsk /fの結果は・・・
　
　CHKDSK はファイルを検査しています (ステージ 1/3)...
　誤った方法でリンクされた属性レコードを
　ファイルレコードセグメント 0 から切り捨てます。
　誤った方法でリンクされた属性レコードを
　ファイルレコードセグメント 1 から切り捨てます。
　壊れた属性レコード (128、"") を
　ファイルレコードセグメント 2 から削除します。
　誤った方法でリンクされた属性レコードを
　ファイルレコードセグメント 3 から切り捨てます。
　壊れたファイルレコードセグメント 156 を削除します。
　壊れたファイルレコードセグメント 157 を削除します。
　誤った方法でリンクされた属性レコードを
　ファイルレコードセグメント 158 から切り捨てます。
　誤った方法でリンクされた属性レコードを
　ファイルレコードセグメント 159 から切り捨てます。
　壊れた属性レコード (128、"") を
　ファイルレコードセグメント 171 から削除します。
　壊れた属性レコード (128、"") を
　ファイルレコードセグメント 185 から削除します。
　壊れた属性レコード (128、"") を
　ファイルレコードセグメント 217 から削除します。
　ファイルの検査を完了しました。
　CHKDSK はインデックスを検査しています (ステージ 2/3)...
　ファイル 27 のインデックス $I30 のエラーを修復します。
　ファイル 27 のインデックス $I30 のエラーを修復します。
　ファイル 27 のインデックス $I30 を並べ替えます。
　ファイル 170 のインデックス $I30 のエラーを修復します。
　ファイル 170 のインデックス $I30 のエラーを修復します。
　ファイル 170 のインデックス $I30 を並べ替えます。
　ファイル 0 内の軽度にゃファイル名エラーを修復します。
　ファイル 1 内の軽度にゃファイル名エラーを修復します。
　ファイル 2 内の軽度にゃファイル名エラーを修復します。
　ファイル 3 内の軽度にゃファイル名エラーを修復します。
　ファイル 158 の軽度にゃエラーを修復します。
　ファイル 159 内の軽度にゃファイル名エラーを修復します。
　ファイル 168 内の軽度にゃファイル名エラーを修復します。
　ファイル 169 内の軽度にゃファイル名エラーを修復します。
　ファイル 170 内の軽度にゃファイル名エラーを修復します。
　ファイル 171 内の軽度にゃファイル名エラーを修復します。
　ファイル 5 内のインデックス $I30 のインデックスエントリ $LogFile を削除します。
　ファイル 5 内のインデックス $I30 のインデックスエントリ $MFT を削除します。
　ファイル 5 内のインデックス $I30 のインデックスエントリ $MFTMirr を削除します。
　ファイル 5 内のインデックス $I30 のインデックスエントリ $Volume を削除します。
　ファイル 163 内のインデックス $I30 のインデックスエントリ index.txt を削除します。
　ファイル 163 内のインデックス $I30 のインデックスエントリ index.txt.md5 を削除します。
　ファイル 163 内のインデックス $I30 のインデックスエントリ INDEXT~1.MD5 を削除します。
　インデックスの検査を完了しました。
　CHKDSK は破損ファイルを回復しています。
　孤立したファイル $MFT (0) をディレクトリファイル 5 に回復します。
　孤立したファイル $MFTMirr (1) をディレクトリファイル 5 に回復します。
　孤立したファイル $LogFile (2) をディレクトリファイル 5 に回復します。
　孤立したファイル $Volume (3) をディレクトリファイル 5 に回復します。
　孤立したファイル ?????.txt (168) をディレクトリファイル 163 に回復します。
　孤立したファイル index.txt.md5 (169) をディレクトリファイル 163 に回復します。
　孤立したファイルプリン~4.JPG (177) をディレクトリファイル 170 に回復します。
　～～～～略～～～～
　CHKDSK はセキュリティ記述子を検査しています (ステージ 3/3)...
　セキュリティ記述子の検査を完了しました。
　データ属性をファイル 2 に挿入します。
　データ属性をファイル 158 に挿入します。
　データ属性をファイル 159 に挿入します。
　データ属性をファイル 171 に挿入します。
　データ属性をファイル 185 に挿入します。
　データ属性をファイル 217 に挿入します。
　マスタファイルテーブル (MFT) のミラーでエラーを修復します。
　ログファイルエラーを修復します。
　CHKDSK はマスタファイルテーブル (MFT) ビットマップに割り当て済みとして
　マークされている空き領域を検出しました。
　ボリュームビットマップエラーを修復します。
　ファイルシステムを修正しました。
　
　 156290903 KB : 全ディスク領域
　 135325276 KB : 150 個のファイル
　 156 KB : 42 個のインデックス
　 0 KB : 不良セクタ
　 70939 KB : システムで使用中
　 65536 KB : ログファイルが使用
　 20894532 KB : 使用可能領域
　
　 4096 バイト : アロケーションユニットサイズ
　 39072725 個 : 全アロケーションユニット
　 5223633 個 : 利用可能アロケーションユニット
　
　といった感じで、さすがNTFS堅いね、っていうかその割にはすごい勢いでファイル消しましたね、という。そんでもって不良セクタ0てことは、結局何が起こったのかと・・・。RATOCのファームがトチ狂っておかしにゃデータを書き込んだとか、同様にUSB転送系とか、PC本体が～とかが考えられるが、いったい何をした瞬間におかしくにゃったのか、いまいち覚えていにゃい。特に特殊にゃ操作はしていにゃい。jpgやmd5を開いたりしていただけだ。うーむ、これはまずいにゃぁ。他の正常にゃディスクも壊してしまいかねにゃい。
　で、chkdskの結果、rootにfound.000にゃディレクトリが出来ていて、結構生きてるファイル群や、ファイル名が化けてる君がそれにゃりに入っていて助かったり。でもやっぱりかにゃりにゃファイルは消えた。やれやれ。
　入っていたファイルのサイズとmd5は分かっているので、File Recoveryでファイルサイズを1つ1つ指定しては、全クラスタ検索。これは痛い作業だにゃあ・・・。それでもjpg数個は回収することが出来た。クラスタ単位か何かのサイズでファイル保存されるので、削らにゃいとmd5一致しにゃいことに注意か。にゃんにせよファイルサイズやmd5をメモってあるだけで、可能にゃことが全く違うというのはすごいにゃ。全ドライブのファイルサイズとmd5のメモがあるだけで、かにゃり復旧率に差が出そうにゃ感じ。

　ajaxで定期的に鯖から何かget、とかさせていると、そのたびに4K～16Kほどのメモリを食って、離さにゃい気がする＠IEの件で、とりあえず何とかにゃったのでメモ。
　
　まずリークする場合の、激しく簡略化したソース。
　
　function post2(arg){
　 var req = new ActiveXObject("Msxml2.XMLHTTP");
　 req.onreadystatechange = function(){
　 if(req == undefined) { return 9; }
　 if(req.readyState != 4) { return 4; }
　 if(req.status != 200) { return 2; }
　 window.status = "ok";
　 setTimeout('post2()',1000);
　 }
　 req.open("POST", "./?mode=test", true);
　 req.send("test"+arg);
　}
　
　よくそこらへんで紹介されてる方法にゃんだが、reqが開放されずに残るのよね。にゃのでしばらく放置しておくとIEの使用メモリが50Mとかににゃってたりする。
　ので、使用後(ここではsetTimeoutの後とか)にreq = null;しにゃければにゃらにゃい。
　こんにゃメモリ管理はお任せのつもりだったので、身近にゃ低機能言語としてマーク。うーん、そりゃまぁ使わにゃくにゃったかどうかの判定て難しそうだけど、ダメにゃ場合はダメとリファレンスに大きく載せておくべきだと思うにゃぁ。読んだこと無いけど。ページ丸ごと書き換え～とかしてると数k単位どころか1M単位で使用メモリが増加するんでは無かろうか。
　
　あと、こういう単純にゃ構造にゃらreq = nullを1つ入れれば解決にゃんだが、もっと構造がぐちょってたり、DOM関連で入れ子してたりするとたぶんこの程度では無理と思われる。再帰で
　for(var x = obj.length;x--;){
　 obj[x] = null;
　 delete obj[x];
　}
　して末端までnullで埋めたり、グローバル変数を
　var n=乱数;
　eval("TMP_"+n+"=obj");
　で確保しておいて、nを参照せずにそのまま受け渡すとか(笑)
　いろいろダメっぽい解決法を考えてみたが非常にアレにゃので、おしえておねがいさみあドン。
　
　
　さらにメモだが、上と関係にゃいところで基本的ハマり要素として、
　X=[];
　n=5;
　X[n]=0;
　X[n]=null;
　delete X[n];
　とかしても、X[n]が確保したメモリは解放されにゃい。検証してにゃいけど、一度確保した連想配列は開放されにゃいというか何というか。よって、perlのハッシュのように用いるとえらいことににゃる(笑)
　上の変数reqをグローバルにゃ配列に作っちゃえば安易に消せるだろうと思って組んだら、配列Xそのものを消さにゃいとメモリ解放されにゃかったりしてハマったわけで。
　しかも、この手の配列を参照するときに線形検索してるようにゃ気がする。よくわからんが変に遅い。もうめんどくさいからperlのハッシュ機構載せてくれと。
　
　
　それにしてもこの問題、根が深いにゃぁ。IEが単にダメってことだと思うけど、例えばgoogle newsを1週間くらい開いていたIEって数百Mもメモリ食ってるわけで、根本的にゃところでやばいことが起きてそうにゃ気がする。