今朝の大規模障害の原因は何だったのだろう？

虎ノ門ニュースを観ようと思ったらずっとグールグル。久しぶりにニコ生を観たけど、プレミアムじゃないとシーク再生できない、こういうところでユーザー失っているのでは？　とは言えこういうときは助かります。コメントシステムもニコニコの方式は優れているのだが、ユーザーエクスペリエンスが低いのでもっぱら YouTube ということになる。

『裸族のカプセルホテル in 2.5』 CRCH2535U3IS

勝手に接続が切れる＆書き込みエラーの発生

しょっぱなから不具合に見舞われました。所有の最大容量12TBのHDDでデータ破壊を心配しましたが、その点は免れたようです。

ちなみに、HDDは新品で単独のHDDケースでは何の問題もありません。HDDの相性と言われるとちょっと困りますが、このHDDに使う予定だったので頂けません。この時点でもう見切りを付けているので、メーカーに見解を求めるメールを発射します。

1. No5とNo4にHDDをインストール
2. No5を認識している状態でNo4をONにしたところNo5の接続が勝手に切れる
3. PC再起動後、No5, No4の順にONにしたところ両方使用できた
4. 念のためNo5のエラーチェックを行ったがエラーなし
5. No5にデータ書き込み中にディスクエラーが発生（書き込みエラーか容量不足と表示／十分空きはある）
6. タスクトレイから停止などが出来ず、No5関連操作の反応が異常に重く、アクセスできなくなる
7. 信頼ができないため使用中止

他のPC、他のHDDでも不具合発生

返品が出来なかったときのために、別のPCで小さい容量のHDDとで試験をすることにしました。No3～5に、2TB（90%使用）、4TB（空っぽ）、1TB（90%使用）とインストールして、4TBにコピーする試験です。

No5→No4のコピー開始直後は問題無さそうだったのですが、しばらくするとデスクトップが消えエクスプローラが異常終了してしまいました。当然コピー中のタスクもろとも、エクスプローラは復元されるものの、コピーは中断されたまま。

これはもう初期不良か、粗悪製品のどちらかで確定でしょう。初期不良として交換してもらっても怖い、このまま使ってたら大事なデータを失うことになりかねません。

転送速度が遅いのも気になる

その後、同じコピーを「玄人志向 KURO-DACHI」にやらせてみたのですが、転送速度が明らかに違いました。同じHDDのセット、同じデータだったから、明らかに違うのが分かりました。ファイル容量によって速度は振れるのですが、カプセルホテルが50MB/sしか出ないところ、玄人志向は最大100MB/s出ていました。

条件はほぼ一緒にもかかわらず、半分程度しか速度が出ていないことになり、正常動作したとしても使いたくはないな。

総合評価：☆☆☆☆☆（星ゼロ）

初期不良だったと考えられますが、お勧めはできません。

メーカーのメールサポートも、書いた内容をちゃんと読んでいない、返信が催促してやっと来る。ユーザーに確認作業を求めたのにも関わらず、その結果に対して何もコメントしないなど、首をかしげる対応でした。センチュリー製品もデフォで選ばないメーカー入りさせていただきます。

お勧めに出てきたので久しぶりに観はじめた。３作品通しで観ようと思ったのに、なぜだか PART 2 が無い。

少し前まではあったみたいだが、勝手に編集されたバージョンが配信されていた（GIGAZINE）とのこと、いまは停止されているらしい。記事によると「現在Netflixで配信されているバージョンは、無修正で未編集のオリジナルバージョンです」とのことですが、どうしても見つかりません。何とか見つけた URL は「現在お住まいの国ではご覧いただけません」だそうです。今後、吹き替えと字幕のバージョンが提供される予定はあるのか、はっきりしてもらいたいなあ。

• バックトゥーザフューチャー（NETFLIX）
• バックトゥーザフューチャー PART 2（NETFLIX）
• バックトゥーザフューチャー PART 3（NETFLIX）

Windows の git bash で git add できないのでハマってしまった。表題のエラーが出るのだが何のことやら、ファイルにはアクセスできるし、メッセージでググっても良く分からない。考えられることを試し尽くして、新しいテキストファイル１個だけのリポジトリにしたにもかかわらず、解消に至りません。

結論から言うと Windows アップデートが原因でした。再起動しようと思ったら、電源アイコンにオレンジのぽっちが付いていたので、再起動待ちになっていたようです。この自動アップデート、本当に腹が立ちます。バックグラウンドで勝手にアップデートしていて、不具合が起こらないようにやってくれるなら分かりますが、それが出来ないなら更新前にユーザーに確認すべきです。前にも同じようなことがありましたが、Windows10 って本当にクソだなって思います。

まとめ

• git add をしようとしても "fatal: fsync error on 'loose object file': bad file descriptor" のエラーが出る
• リポジトリはネットワークディレクトリ上にある（ファイルサーバーの共有フォルダをネットワークドライブにマウント）
• ネットワークドライブからは問題無くアクセスできる
• エクスプローラから "\\server" のホスト名でアクセスできない（再起動直前に気づいた）
• エクスプローラから "\\<IPアドレス>" だとアクセスできる
• "ping <ホスト名>" はエラー、"ping <IPアドレス>" は IPv6 で返って来る
• ちなみにネットワークドライブ自体は、ホスト名で登録していて問題無くアクセス出来る
• Windows アップデートが再起動待ちになっていた
• 再起動後はネットワークアクセスも、git add も問題解消していた

教訓

Windows で問題が起きたら、あれこれ試す前に再起動すべし。

http サイトからのダウンロードだと「このファイルは安全にダウンロードできません」となって、継続できるっぽいボタンが出てくるけど無反応、完全にダウンロードできなくなってしまいました。今日アップデートした Chrome だけなので、これはアップデートが原因ですね。http を完全に排除してしまったのか、そうだとすると Chrome から離れるユーザーも出てくるかも知れません。

• http からダウンロードできないバージョン：86.0.4240.75（Official Build） （64 ビット）
• http からダウンロードできるバージョン：85.0.4183.121（Official Build） （64 ビット）

別にいいんだけど、ウェブアプリ開発サーバーで http が使えないと少し面倒いなあと思います。オレオレ証明書でもいいでしょうが、ひと手間増えてしまうので任意で続行できるように改善してもらいたいです。

Firefox「はい！僕ダウンロードできます！」

いずれ Firefox も追従するような気もするが、利用者獲得に使ってやろう的なことを画策していたりして。

ずっとマルチカードリーダーみたいなものが付いているからだと思っていたましたが、考えてみると BD-ROM っておかしいよな、ということで調べてみました。現象は、BD-ROM ドライブが大量に存在しているかのように表示される、というもの。

本物の BD-ROM ドライブが分かり難いのと、ドライブレターが使えないのを除けば、特に害は無いがちょっと気になります。ここからプロパティを開くと、BUFFALO の表示がありますが、心当たりのある製品は使用していません。カードリーダーは Transcend だし、BD-ROM はパイオニアなので、ちょっと怪しくなって焦り出す。

デバイスマネージャを開いてみると、"DiscSoft Virtual SCSI CdRom Device" と表示されています。ヴァーチャルドライブと聞いて、Windows 7 の頃 DAEMON Tools lite ってのを使っていたのを思い出しました。Windows10 にアップデートしたとき、スタートメニューからもトレイからも消えていたのでそのまま忘れていたようです。

ネット検索からも確認できたので、DAEMON Tools をアンインストールすることにします。光学メディア自体ほとんど使わなくなっているので、仮想光学ドライブも同様、速やかに削除することにします。

見えなくなっていてもアプリの一覧を確認したところ、しっかり残っていましたので、通常どおりアンインストールしました。結果、物理ドライブのみのすっきりとしたドライブ一覧になり大満足です。

光学ドライブもフロッピーと同じく、忘れさられる時代がすぐそこまで来ている気がしました。

BitLocker を有効にしようとして「アクセスが拒否されました。」となる件ですが、リモートデスクトップで操作しているためでした。サーバー的に使っている PC だとモニタを繋いでない場合があるので、地味に面倒な仕様です。外付け HDD の場合は、他の PC で BitLocker を設定すれば良いですが、内臓 HDD の場合はモニタ繋ぐしかないですね。

こんな変な仕様なら、エラーメッセージを適切にしてもらいたいものです。リモートデスクトップだと何が問題なんでしょう？　マイクロソフトは相変わらずダメダメですね。

ちょっとした自動処理にクローラみたいなプログラムを動かしているんだけど、先月末ぐらいからうまく動かなくなっていたらしく表題のエラーログが出ていた。今まで問題なく動いてたので、相手サービスの仕様変更かとずっと調べていましたが、原因は単純ミスだったようです。

エラーメッセージの文字通り、ヘッダ情報の出力が間違っていただけでした。今までは間違ったままのヘッダでも処理してくれていたようですが、ウェブサーバーのアップデートか何かでエラーを吐くようになったっぽい。そのままでも行けるサイトもあり、Apache か nginx かアップデートされたか、されてないかの違いでは無いだろうか。

前回は CSS のみでテーブルヘッダを固定する方法を紹介しました。ただ、ページ構成によっては position: sticky; が効かない場合があるため、今回は JavaScript を使う方法を紹介します。jQuery には高機能なプラグインがありますが、実装が複雑なためか動作が不安定になることがありますが、余計な機能はいらないならこれで十分です。

<div class="scrollbox">
	<div class="innerbox">
		<table class="tablefix">
			<thead>
				<tr><th></th></tr>
			</thead>
			<tbody>
				<tr><td></td></tr>
			</tbody>
		</table>
	</div>
</div>

.scrollbox {
	position: relative;
	width: 100%;
	height: 30em;
	overflow: scroll;
	border: 1px solid gray;
}

.innerbox {
	padding: 1em;
	display: table-cell;
}

.tablefix {
	border-collapse: separate;
	border-spacing: 0px;
	border-bottom: 1px solid #dddddd;
	border-right: 1px solid #dddddd;
}

.tablefix thead th {
	position: relative;
	white-space: nowrap;
	background-color: #e3e3e3;
}

.tablefix th,
.tablefix td {
	border-top: 1px solid #dddddd;
	border-left: 1px solid #dddddd;
	padding: 0.5em;
}

$(function(){

	$('.scrollbox').scroll(function(e){
		let th_top = $(this).find('.tablefix').position().top;
		let filter;

		if (th_top>=0) {
			th_top = 0;
			filter = 'unset';
		} else {
			th_top = -th_top-1;
			filter = 'drop-shadow(0px 4px 0px #00000040) drop-shadow(0px 2px 0px #00000040)';
		}

		$(this).find('.tablefix thead th').css({
			top: th_top,
			filter: filter
		});
	});

});

.tablefix {
	border-collapse: separate;
	border-spacing: 0;
	border: 1px solid #dddddd;
}

.tablefix th,
.tablefix td {
	border: 1px solid #dddddd;
}

CSS の display: sticky を使うことで、jQuery などの JavaScript を使わずにテーブルヘッダの固定が出来ます。若干、扱いが難しい面もありますが、不安定なプラグインの動作に悩まされることなく手軽に導入できます。

サンプル

HTML

<div class="scrollbox">
	<div class="innerbox">
		<table class="tablefix">
			<thead>
				<tr><th></th></tr>
			</thead>
			<tbody>
				<tr><td></td></tr>
			</tbody>
		</table>
	</div>
</div>

CSS

.scrollbox {
	position: relative;
	width: 100%;
	height: 30em;
	overflow: scroll;
	border: 1px solid gray;
}

.innerbox {
	padding: 1em;
	display: table-cell;
}

.tablefix {
	border-collapse: separate;
	border-spacing: 0px;
	border: 1px solid #dddddd;
}

.tablefix thead th {
	position: sticky;
	top: 0;
	white-space: nowrap;
	background-color: #e3e3e3;
}

.tablefix th,
.tablefix td {
	border: 1px solid #dddddd;
	padding: 0.5em;
}

解説

Firefox のバグに対応

テーブルを border-collapse: collapse; にして th に position: sticky; を設定すると、firefox 系で枠線（の右側と下側）が消えるバグが発生します。このためテーブルを border-collapse: separate; border-spacing: 0px; にしています。この場合、枠線の太さを 2px にする場合と 1px にする場合とで工夫が必要になります。

枠線の太さを 2px にする場合

table, th, td の３つに 1px の枠線を付けます（サンプルの方法）。

枠線の太さを 1px にする場合

table の右と下に 1px の枠線、th, td の左と上に 1px の枠線を付けます。

.tablefix {
	border-bottom: 1px solid #dddddd;
	border-right: 1px solid #dddddd;
}

.tablefix th,
.tablefix td {
	border-top: 1px solid #dddddd;
	border-left: 1px solid #dddddd;
}

innerbox について

scrollbox 内でスクロールさせたとき、padding（もくしはテーブルの margin）がうまく適用されない点について修正しています。これ（display: table-cell;）が無いと、右側へスクロールさせても余白がありません。また、Firefox と Chrome で下側へのスクロールで違いがあります。

なお、スクロールボックス内に入れない場合や、余白が必要ない場合は必要ありません。