まるっとお見通した

http://mixi.jp/view_diary.pl?id=16483796&owner_id=26484
昨日の雪景色の写真が消えてる。

俺が消したわけではない。
温泉側から消すことも権限上不可能。
クラックか?とか一瞬だけ考えたが、こんなピンポイントの
ファイルだけを狙う必然性がない。

状況を考える。
1.5/6のタイムスタンプでの更新が2つあった。
2.写真も同じものが2つ。
  (画像ファイル名が同じのものが2つ並んでいた)
3.藻琴山温泉はナローバンド環境。

そしてスクリプトの仕様。
1.アップロードCGIにアクセスした時点で、time関数を使って
  
  みたいな感じで10桁の画像IDを仕込む。
2.「画像ID.jpg」で写真アップした後で、そのナンバーを
  引き継いでコラム入力フォームが出現。
3.確定すると記録ファイルにcsv形式で記録される。
  (画像ナンバー\t内容\tほか\n)
4.column.cgiは記録ファイルを読み取り、解析。
  画像ナンバーを利用して日付を算出して、表示する。


同じ日付の記録が2つ並んだということは、スクリプト
「1」の段階で前回と同じ画像ナンバーが出現してしまった
可能性が高い。
そしてそのままアップロード作業を続けたため、前日の画像が
上書きされた。
そう、あれは消えたのではなく、上書きされたのだ。

では何故同じ画像ナンバーが出現してしまったのか。
それは状況の「3」に原因があると思われる。

まれにみるナローバンド環境である芝桜公園では、おそらく
可能な限りデータの読み込みを抑えようとして、アップロード
CGIまでは「オフライン作業」状態で繋いだのだ。

キャッシュデータのため、当然ながら画像ナンバーは前日の
データのまま。
画像をアップロードするボタンを押した時に、初めてダイアル
アップ接続が発生したわけだ。

前日と同じナンバーでアップロードの指示が来たため、画像
ファイルはそのまま上書きされる。
そしてその画像ナンバーが記事入力フォームにも受け継がれて
しまったために、
記事のCSVファイルにも前日の日付がそのまま書き込まれる。
無論、column.cgiはそのナンバーを解析して、前日と同じ日付を
表示する。

状況証拠からの推測だが、おそらく間違いないだろう。
嗚呼、現実は常に想像の斜め上を行く

アップロードボタンが押された段階で、CGI内部でナンバーを
生成するようにして解決。
はじめからこうしろよと俺に言いたい。