アカウント名:
パスワード:
以前みたカウンタCGIプログラムは、同一ファイルに対してread/writeしていました。ディスクフルは想定していなかったようで、書き込みオープンはできても実際の書き込みはできず、結果としてデータ消失(カウンタリセット)していました。
この場合、いったん別ファイルに出力して、すべて成功したら旧ファイルをリネームで置き換える、でいいのかな。
Here's a much better web-page hit counter: $hits = int( (time() - 850_000_000) / rand(1_000) );If the count doesn't impress your friends, then the code might. :-)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
ディスクフルを想定したプログラミング (スコア:0)
Cで言うfwrite()の返り値のチェックとか、ちゃんとやっています? オープン時のチェックはやっても、その後は成功すると仮定してたり。
以前みたカウンタCGIプログラムは、同一ファイルに対してread/writeしていました。ディスクフルは想定していなかったようで、書き込みオープンはできても実際の書き込みはできず、結果としてデータ消失(カウンタリセット)していました。
この場合、いったん別ファイルに出力して、すべて成功したら旧ファイルをリネームで置き換える、でいいのかな。
Re:ディスクフルを想定したプログラミング (スコア:1)
書き込む直前のftruncate()されたタイミングで読み込んでしまって、なにもなかったから0として扱われたんじゃ?
リネーム前に複数回読み込まれたら、正確なカウントができません。
素直にreadしてからwriteするまでの間をロックすればいいかと。
ついでにperlfaqから引用
Re:ディスクフルを想定したプログラミング (スコア:0)
ロック処理はありました…って書いていないですね。すみません。
厳密な検証はしていないのですが、もしロックが原因であれば、ディスクフルにかかわらず、たまにリセットされるはず。問題がおきたのは、ディスクフルのときだけでした。
ディスクフル状態、さまざまなプロセスがディスクの空きができるのを待っている状態で、カウンタデータを書き戻すときにいったんtruncateしたと同時に持っていかれたのではないかと、当時予想しました。
個人的に、ウェブサイトのアクセスカウンタなんて、自分とこの人気のなさを世界に公開するので付けるべきでないと思うのですが、そうは思わない人もいたようです(10年前)。
Re:ディスクフルを想定したプログラミング (スコア:1)
読み書きモードでオープン→ロック→データ読み込み→truncateしてサイズ0に→データ書き込み
だと、ディスクフルの時にデータ書き込みができませんね。サイズを0にした時点であとは何もできなくなります。
(UNIX系だと、空き容量マイナスになりえるので、その場合、ファイルサイズの変わらないような既存のファイルの更新はできるけど、ファイルサイズ(必要セクタ数)を増やすことがまったく出来なくなる)
読み書きモードでオープン→ロック→データ読み込み→先頭にシーク→データ書き込み→現在位置までtruncate
なら大丈夫。
更新後のデータ書き込みで必要なセクタ数が増加するような場合は問題が起きますが、そんな桁数のカウンタはまず無いでしょう。
あ、カウンターだったらそもそもファイルサイズが減ることないからtruncateしなくてもいいのか?