SVX日記

　 土曜日、もうひとつ帽子を作ってもらおうと、岡崎に向かった。たまたま、近日中に中学の友人と会う機会があるので、愛用のX100Sを持ち出す。オイラは岡崎の中学に通っていたのだよね。いま、学校がどんな様子なのか、写真を眺めて酒の肴にしようって寸法だ。

　 予定通り、帽子を注文し、中学校の周りをウロウロしながら写真を撮りまくり、JR岡崎駅を回って、名鉄東岡崎駅へ、毎日のように通った通学ルートを辿る。想像よりも、変わってない印象だ。懐かしい。

　 で、家に帰って驚いた……写真がダウンロードされない……最初、自作のスクリプトのバグかと思い、カメラの再生モードで写真を探すが……やっぱりない……えー、まじー!? 先日自作したバッテリ充電器の写真が最後になっている。撮ってない……わけないよな……撮った直後に再生モードでピントチェックとかもしたよな……な、なんで!?

　 と、あれこれしているうちに、なんと問題が再現した。撮って、電源を切って、電源を入れて、再生モードにすると、撮ったはずの写真がないのだ。撮った直後、電源を切らないうちは、再生モードで撮った写真が確認できる。なんだこの症状。記録したつもりで記録していないってこと？ カメラのバグか？

　 X100Sはプロユースの機器とまでは言えないが、準フラッグシップの位置づけだろう。メーカーもさすがに「まぁ、なんていうの、そんなこともあるよね」などとはいわないはず。とりあえず、富士フイルムに依頼を依頼するメールを出してみた。

　 で、今日、さらに問題の切り分けを行った。具体的には、問題が起きているSDカードをPCに挿し、その内容を別のSDカードにddでフルコピーする。でもって、フルコピーしたSDカードをカメラに入れて、同様の事象が起こるか確認する。これで問題が再現すれば、SDカード上の記録内容に問題があるという事になり、カメラ被疑の可能性が高くなる……が、同様の事象は起こらなかった。

　 そーなると、SDカード側の問題か？ PCに挿してある問題のSDカードに書き込み、いったん抜いて、また挿して……げー！ 問題が再現するではないか。書き込んだはずのファイルが消失しているッ！

# SD カードを挿す
 
bragza /root # mount /dev/sdb1 /mnt/temp
 
bragza /root # ls -n /mnt/temp
合計 32
drwx------ 3 1000 1000    32768 10月 18 23:00 DCIM/
 
bragza /root # cp google-chrome-38-0-2125-104-64-bits-multi-ubu.deb /mnt/temp
※そこそこの大きさのファイルを書き込む
 
bragza /root # ls -n /mnt/temp
合計 46592
drwx------ 3 1000 1000    32768 10月 18 23:00 DCIM/
-rw-r--r-- 1 1000 1000 47670984 10月 30 23:10 google-chrome-38-0-2125-104-64-bits-multi-ubu.deb
 
bragza /root # echo 3 > /proc/sys/vm/drop_caches 
※キャッシュをドロップ
 
bragza /root # md5sum google-chrome-38-0-2125-104-64-bits-multi-ubu.deb 
a2b61a623da973f12e1cb18674b9fb93  google-chrome-38-0-2125-104-64-bits-multi-ubu.deb
 
bragza /root # md5sum /mnt/temp/google-chrome-38-0-2125-104-64-bits-multi-ubu.deb 
a2b61a623da973f12e1cb18674b9fb93  /mnt/temp/google-chrome-38-0-2125-104-64-bits-multi-ubu.deb
※そこそこ時間を要したことから、キャッシュの影響ではないことが確認できる
 
bragza /root # umount /mnt/temp
 
# SD カードを抜き差しする
 
bragza /root # mount /dev/sdb1 /mnt/temp
 
bragza /root # ls -n /mnt/temp
合計 32
drwx------ 3 1000 1000 32768 10月 18 23:00 DCIM/
※記録されてない……そんなアホな!?
 
bragza /root # 

　 これは明らかにSDカードに起因する障害だ。こんな壊れ方あり!?

　 ちょっとググると、なんと同様の症状の報告があるではないか。「SDカードが壊れました！コピーや削除してもカードを抜くと元に戻ります！フォーマットもできません！」。マジかよ。

　 ちなみに、オイラのSDカードもTranscend。microSDHC 4GB class6だから、かなり古い。にしても、こんな嫌がらせのような壊れ方はないんじゃないか。しかも、上記の例がSDXCだという事を考えると「現象を知りつつ、長らく改善してない」ってことになる。ふざけんな。記録できてないなら、記録できてない旨を応答するだけのことだろ。フェールセーフ的にありえない設計だ。製品として腐っていると言ってよいのではないか。

　 数10MBの書き込みが行われた場合、カメラ上のキャッシュや、SDカード上のキャッシュの影響により「書き込まれたかのように見える」という事はないだろう。それほどの量のデータを保持できるほどのキャッシュ容量を持っているとは思えないからだ。間違いなく、SDカードのフラッシュメモリにまで記録は行われ、カメラはフラッシュメモリからその記録を読んで画像を再生しているはず。PCでmd5を実行した場合に、そこそこ時間を要したこともそれを裏付けている。

　 とすれば、考えられるのは、SDカード上のメタデータ管理にまつわる不具合だ。フラッシュメモリは同じ場所に書き込むとメモリセルの疲弊が進むことから、実は上書き動作は行わず「別の場所」に書いて、メタデータを書き換えることで、あたかも上書きしたかのように振る舞う。いわゆるウェアレベリングというやつだ。今回の問題は、そのメタデータ部分のみ、記録しない動作になってしまっているため、電源を切るまでは「別の場所」にアクセスできるが、電源を切ると「別の場所」に書いたこと自体を忘れてしまう、という状態なのではないか。これをやられると、カメラやPC側からそれを検知する術はない。完全にSDカードのファームウェアロジックのバグだといえよう。SuperDoahoカード。

　 安物買いするとこういうことになるんだな。勉強になったわ。悪いがこんなことは2度とごめんだ。Transcendのメモリはたくさんあるが、全部ゴミ箱行き。Transcendのメモリは永久保証らしいが、交換してもらうどころか、2度と使う気にならんわ。さらば、大酋長サイクロプロス。

　 甲での撃破は難しいかと思っていたが、なんと、削りに7回、最終形態2回目にしてアッサリ撃破。決めたのは大井。この後、北上が決めてS勝利だった。

　 実は、休憩所などと評されているE4で、出撃15回の大苦戦の後だったりする。どうも最近、実生活も含め自分の周囲で羅針盤が荒ぶりすぎている気がする。不意に頓死しないように気をつけないと……。

　 かなりひさびさに都内に出張ということで、早朝7時過ぎに名古屋駅新幹線ホーム到着。乗車までやや時間があったので、朝食にきしめんを掻きこんだあと、ちょっと記録をばと、愛用のX100Sを取り出して写真を取ろうとしたところ、なんと電源が入らない……。

　 昨晩、準備万端に、満充電したバッテリを入れ忘れた模様……アホかオレは。

　 こういう時、RICHOのデジカメは単3が使えてよかったよなぁ、とか思いつつ、今回はあきらめるしかない。先日、SDカードにさんざん悪態をついた挙句になんだが「まぁ、なんていうの、そんなこともあるよね」。

　 新幹線の中では、久々にガッツリとKOBOで読書。出張の目的を果たして、予定通り、品川で中学時代の2人の友人と合流。実に20年ぶりくらいなんだが、3人とも、サッサと脳みそを桜色に染めてしまい、実に20年ぶりなのに、なんともアホな話題に終始してしまった気がする。なんか、ひとつの話題について3回くらいずつ繰り返してた気もするな。まぁ、楽しかったからいいんだけど。

　 秋葉のカプセルホテル泊。寝るだけだが、悪くなかった。

　 秋葉のカプセルホテルで起床。ここの目覚ましは、まず照明の点灯、しばらくの後、照明の点滅と控えめなブザー。この起こし方、悪くないなぁ。愛用の行灯にも、似たようなアラーム機能をつけようかしらん。

　 起き出して、秋葉を徘徊。デニーズで朝飯。そして、久々のトライアミューズメントタワー。ダライアスエキストラバージョン。ウェーブで上のZを一発クリア。次はロストワールド。これまで何度も余裕のワンコインクリアをしてたはずなのだが、なぜか攻略法をロストしてて武神で連敗。くそ。

　 各種部品を買い漁りつつ、先日のSuperDoahoカードの代わりとなる、マトモなSDカードを物色する。やはりここはサンディスクだろう。別に、そう大容量でも、そう超高速でなくてもいいが、ニセモノをつかまされないように、できるだけマトモっぽい店を選ぶ。なにせ、Amazonの出品が怪しすぎたこともあって、実店舗で買うことにしたわけだし。

　 で、テクノハウス東映。ところが、エラく類似しているカードが並んでいて混乱する。なんじゃこりゃ。

　 なんでも、主に読み書き速度で差別化された製品ランクとして、スタンダード、ウルトラ、ウルトラプラス、エクストリーム、エクストリームプラス、エクストリームプロがあり、それぞれ、異なる容量のものがあり、さらに、新旧モデルがある。まさに三次元的商品展開。

　 オイラの使い方だと、それほど大きな容量は必要なく、8GBか16GB程度でよいので、その辺りのモデルを比較したのだが、なぜかエクストリームにも2種類あり……

・Read 60MB/s, Write 40MB/s, UHS Speed Class 3, 1,950円
・Read 45MB/s, Write 45MB/s, UHS Speed Class 1, 1,750円

　 ……となっている。どうも、これが新旧モデルらしい。後者の方が、前者よりもWriteが速いにも関わらず少しばかり安い。こんなの、どう考えても後者やんか。どうやら、モデルチェンジを機にこっそり実質性能を落としたということのようだ。ったく、油断も隙もないな。

　 しかし、この価格でサンディスクが買えるなら、トランセンドなんて買う理屈がないな。ポルシェがちょっと高級な軽を売ってるようなもんだ。

　 そのまま秋月に入るが、先日、通販で大量に買ったこともあり、激混みに負けて何も買わず。千石でタミヤコネクタ等を購入しつつ、あきばお〜で激安の無線LANルータWRH-300WH-Sを購入。いや、来月にしばらくホテル住まいの予定があるもんで。

　 ヒロセテクニカルを経由して、日米商事で適当にコンデンサを購入して仕上げ。やることなくなったんで、新幹線の時間を早め、シュウマイをつまみにワンカップをやりつつ帰宅した。

　 やっぱり季節に一度くらいは秋葉を回りたいもんだなあ。

　 LinuxはCUIによる設定が中心であるため、各種設定の記録が残しやすく、残しておいた各種記録はノウハウとして有用だ。しかし、その記録をどこに残しておくかが問題で、後で見返せないようなら意味がない。

　 今回、例によって各種設定の記録を残しながら業務サーバの構築を行なっていたのだが、構築中のサーバ上にHikiを導入し、その上に記録を残すことを思いついた。もしオイラが頓死しても、記録が見つかれば他の誰かがメンテナンスを引き継げる可能性がある。

　 というわけで「Ubuntu 14.04.1 LTS」上にHikiを導入しようかと思ったら、Ubuntuのリポジトリ上にあるのね。こりゃ楽でいいや。aptitudeでひょいと入れる。

/root # aptitude install hiki

　 setup用スクリプトまである。使い方がよくわからんので、当てずっぽうで実行する。当たった。

/home/user $ mkdir public_html/hiki
/home/user $ hikisetup --lang ja public_html/hiki
/home/user $ vi /home/user/public_html/hiki/hikiconf.rb

　 ところが、うまく動かない。Ubuntuの場合、ユーザ権限で動作させるときは、suexec版を入れる必要があるようだ。といっても、作業はこれだけ。

/root # aptitude install apache2-suexec
/home/user $ chmod 755 public_html/

　 アッサリ動いたなぁ、と感心しつつ、自作のメーラ「mave」から文書の編集作業が行える(現公開バージョンには未搭載)よう設定してみる。既存文書は読み込めるが、文書の更新ができない。しばらく機能を使ってないし、潜在バグでも残っていたかと思って、ブラウザ上からの更新を試してみたところ、なんと、ブラウザ上からもダメ。「指定したタイトルは既に存在しています。」なんて出る。なんや、Hikiのバグやんか。

　 どうやら、文書のタイトルが多バイト文字の場合のみ、問題が出るらしい。「指定したタイトルは既に存在しています。」というメッセージから、逆にコードを追っていったところ、文書の既存チェック部分でコケていた。エンコーディングの変換を忘れてる。

/usr/share/hiki/hiki # diff -bc command.rb.org command.rb
*** command.rb.org	2014-01-17 01:02:29.000000000 +0900
--- command.rb	2015-02-27 17:28:04.915669859 +0900
***************
*** 553,558 ****
--- 553,559 ----
        end
  
        p = (@db.select {|p| p[:title] and unescape(p[:title]) == page})[0]
+       p.force_encoding('UTF-8')
        if p != @p and p != nil
          return p
        end

　 上記1行の追加で、無事、文書の更新ができるようになった。

　 しかし、こんなバグが残ってるってことは、もうHikiを使ってる人は少ないのだろうか。まぁ、機能的には現状で十分だし、Rubyなら自分で直せるから開発が止まっていても困らないが、ちょっとサミしいなぁ。