なぜflockを嫌うんだ、ボゲェ！

flcokは使えない環境があるからmkdirを使った方法がベストとかアホなこと
ほざいてるCGI配布サイトは逝ってよし。
UNIXとNTで使えるんだから、あとはローカルテスト用にevalでくくっとけば
万全だろうが。
いまどき商用サーバでWin9x系使ってるところがあるのかよ。

つ〜か元々ねぇよ、Win9x系の商用サーバなんて。

>なぜflockを嫌うんだ、ボゲェ！
お前みたいなヤツが居るから

------------------------完---------------------------

CGIを設置する全ての人が、商用サーバを使ってると思っているのがイタイ。
意志の疎通は不可能だな。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
　　　　　　　　　　　　　　　　　fin
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

flock は精度低いから逝ってよいだろ？

ＣＧＩを配布する側としてはロック方式の選択等と言う一般人になじみのないことを
利用者に選ばせたくないし、かといってイントラネットでの利用やローカル
環境でのテストのことを考えるとflockはちょっと敬遠したくなってしまう
ので結局mkdirになってしまうって感じです。

どっちにしろflock使わずにsymlink使ってるよりはましでは？
flock使えるのになぜsymlink?って言いたい。

flcok関数が使えるのは１の脳内環境くらい。

>>6
ごめん、同じこと言うけど精度低いから。
symlink にしてからは二重化していなくてもデータ飛んでないからなあ。
別に配布するわけじゃないからかまわんよね。

Linuxのflockは不安定。

そうなの？
これ別にいやみでいうわけじゃないけど､flockの使い方が間違ってたって
事ないですか？

flockを使っていたときは、サーバーが不安定になるとよく
データが飛んでました。
初心者ですが、解説書見て念入りに点検した結果なんですけど…。

＞Linuxのflockは不安定。
これは知らなかったよん。
うちのサーバはFreeBSDだから助かってるの？
flockで一回もデータが飛んだことないんだけど。
そういやLinuxのシステムコールはfcntlが基本で、
flockはあとから追加されたんだっけか？

>7
やっと意味がわかった（ｗ

調べてみたけど間違えてはいないと思う。
flock(FILE＠｀8) せずに close してるし。
でもそのうち mkdir と symlink と flock の強度実験はしてみようかな。

http://www.interq.or.jp/www-user/somucho/perl/flock.html#03
でちょっとだけ詳しく取り扱ってる。

ふふ。
もっと、もっと巨大なサーバ群で使ってみ。
二度と使うかって、後悔するから。

flcokを使えないＯＳ（9ｘとか）でWebを公開する状況って
どういうことよ？
イントラならほとんどNTだし、ローカルテストは排他制御不要
だから１の言う通りevalで問題なし。
初心者に配るのが目的ならなおさらflockがいいと思うが。

> flcokを使えないＯＳ（9ｘとか）でWebを公開する状況って
> どういうことよ？
Webを公開せんでも改造してローカル(Win 9x)でテストするヤツはいるだろーがよ。
初心者ならなおさらだ（ｗ
もちっとノーミソ使え、ボケ。

だからevalでくくれって書いてあるだろうが。
ローカルテストに排他は不要だろ。初心者ならなおのことだ。
てめぇこそノーミス使え。ボケカス。

1、16＞同感

Win9xマシンでWeb公開か？
そんなマシンで排他制御しなきゃいけないくらいの
アクセスあんのか？普通にマシン落ちるべ？？
ってか落とす。ﾜﾗ

誰か最強の排他制御のコード考えて。

>いまどき商用サーバでWin9x系使ってるところ

「いまどき」ではなくてもともと無い

open(FILE＠｀ "+<$file");
eval{ flock(FILE＠｀ 2); }
#
# ここに読みコード
#
seek(FILE＠｀ 0. 0);
#
# ここに書きコード
#
truncate(FILE＠｀ 0＠｀ tell);
close(FILE);

20＞2とカブってんだよ。レス短いんだから読めよ。ボケ。

21＞17みたいな読解能力の無い厨房の為に解説も付けてあげなよ。ﾜﾗ

「いまどき商用サーバでWin9x系使ってるところ」に同意してる
っていう揚げ足とりだろ

↑変わんねーよ。

　　 ●　 ●　　　　　　　　　●　●　　　　　　　　　　　　　　　　　　　●●●
　 ●　 ●　●　●●●　●　●　●　　　　　　　　　　　　　　　　　●　　　●
　●　　　●　　　●　●　　●　　　●　　　●　●　　　　　　　　　　　　　●
●　　　　　　　　 ●　●　　　　　　　●　　　●　●　　　　　　　　　　　　●
●　　　　　　　　●　　●　　　　　　 ●　　　●　●　　●●●●　　　●
●　　　　　　　　●　　●　　　　　　 ●　　●　　　●　　　●●　　　　●
　●　　　　　　●●●●●　　　　 ●　　●　　　　●　　●
　　●　　　　　　　　　　　　　　　 ●　　　　　　　　　　　●　　　　　　　 ●

カブってんじゃねーよ、カブらせてんだよ、ボケ

27＞
ネタだろ？ （'Д'）y ─┛~~

　　 ●　 ●　　　　　　　　　●　●
　 ●　 ●　●　●●●　●　●　●　　　　　　　　　　●　●　　　　　　●
　●　　　●　　　●　●　　●　　　●　　　●●●●　●　●　　●　　●
●　　　　　　　　 ●　●　　　　　　　●　　　　　　　●　　　　　　 ●　　●　 ●　●●●●●
●　　　　　　　　●　　●　　　　　　 ●　　　　　　　●　　　　　　●　　 ●　●　　　 ●　●
●　　　　　　　　●　　●　　　　　　 ●　　　　　　　●　　　　　 ●　　　● ●　　 　　●●
　●　　　　　　●●●●●　　　　 ●　　　●●●● 　　　　 ●　　　　●●　　　　 ●
　　●　　　　　　　　　　　　　　　 ●　　　　　　　　　　　　　　　　　　　　　　　　　　　●

NFSだと泣くよ

つーか、各々好きなもん使えば良いだろ。


----------------------- 完 ------------------------

NFSだとダメってのも盲信。
NFS環境下でロックが効かないのは、異なるサーバからの同時アクセスだけ。
それが起こりうる環境ならNGだが、そんなプロバはまず存在しない。

Win98でサーバたててる人から、「Winでも動くのでありがたいです」
というメール、カキコ多数あるからなぁ…。
逆に、なぜflock以外がダメなのか知りたい（私はrenameで）。

つーか、各々好きなもん使えば良いだろ。


----------------------- 完 ------------------------

うーむ、ディレクトリをNFS共有して多重化されてる
httpサーバーって普通にあると思うんだが……。例えばRimnet。

んでまあ、symlinkならNFSごしでも大丈夫かってーのは
よく知らん。スマソ。

最近のPC-UNIXってよくわかんないんで、聞きたいんだが、
確かFreeBSD/Linuxのstatd/lockdって、うまく動かないんじゃ
なかったっけ？最新バージョンならちゃんと実装されているのかな？
ダミー実装のままでも、NFSのファイル排他制御ができるのかな？

もちろんSolarisなどで運用しているところならいいんだろうけど。

>>36 FreeBSDは実装されてないのでうまく動きません(RELEASE-4.1)。
Linuxは実装されてたと記憶します。限界状況ではSolarisの方が安心だと思います。

>>35 symlink(等)はNFSサーバ側でシリアライズされるので大丈夫です。

>>33 (NFS越しでなければ)flockはカーネル内のメモリ操作で処理が
完結しますが、それ以外の方法はI/Oアクセスを伴うので余計なオーバーヘッドが
かかります。

>>21 flock()が常に成功する、という仮定は危険です。OSの資源が不足した
り、何らかのsignalを受けるとflock()がエラーを返して終了し、競合が発生
する可能性があります。

ためになったのでage

flock萌えあげ

flock ださすぎ
排他モードでオープンとか無いんですか？

perlってセマフォ関連の関数ってないんだっけ？

man perlipc

>>40
それを言うんであればダサすぎなのはopen関数。

40ってなんにもわかってないんだろうな

みなその人なりにわかっていないものです。あなたも、わたしも。

WindowsのCreateFileしか知らん
44も知ったかぶりやろうと見たが

ロック対象のファイルをちょっと人力で編集したいとき、
symlink方式だと「touch lock」とかやってロックできるので便利。
ただし作業終了後にrmし忘れると悲惨。

flockだったらどうやる? ワンライナーでやる?
perl -MFcntl=:flock -e 'flock(STDOUT＠｀ LOCK_EX); select(""＠｀""＠｀""＠｀undef)' >> file

>ただし作業終了後にrmし忘れると悲惨。
俺それやって偉い怒られた。
それがトラウマになって、運用開始してからのCGI入れ替えはやらないことにしてる。

最強のろっくきぼんぬ
professionalなお方

my $fh = new IO::File ("access.log"＠｀ O_WRONLY|O_CREAT);

if (defined $fh) {
&nbsp;&nbsp;&nbsp;&nbsp;if (flock ($fh＠｀ 2)) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (truncate ($fh＠｀ 0)) {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$fh->print($data);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;undef $fh;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;}
}

最強ってのはないんじゃないかな。
汎用性と使い勝手で考えるなら mkdir 使ったロックかな。

>>47 コマンドラインからなにがしかのオプションをつけて起動されたときには、
lockして一定時間sleepする機能をあらかじめ用意しておくと便利だと思います。
ロックの解除忘れの心配が少なくなります。

>>49 flockで必要十分です。
ただし、システムコールのエラーのハンドリングはしっかりと。
signalも考慮してください。
プロセスはいつ殺されるかわからないので、ストレージ上のデータ
が中途半端な状態になる期間を極力短くし、またそうなっても検出できる、
あるいは致命的にならないように、ロジックやデータ構造を工夫して
ください。

>>50 もしそれが許容されるなら、データ長を固定長にすれば
truncateが不要になるので、flockも不要になります。(syswriteを使用する)
ただ、アクセスログならば追加書き込みするのが普通だと思いますが…
追記の場合もsyswriteすれば、flock不要です。

>49
http://www2q.biglobe.ne.jp/~terra/cgi/lockfile.htm

>>49
http://www.din.or.jp/~ohzaki/perl.htm#File_Lock

flock 使ったことのない者の意見ですが、flock って
advisory lock でしょ？
なら lockfile を別ファイルにしといて中にロックしてる
プロセスのPID書いておけば、意味無し lock は検出できるような
気がしますが。
もっと話が複雑なのかな。

＞もっと話が複雑なのかな。
そうです。
世界はあなたのおよびもつかない所で動いているのです。

なるほど。mkdirは目ウロコ >>51

ファイルを使ってロックを実現するのは容易ですが
何らかの原因で残ってしまったロックファイルを、
安全に取り除くのはとても面倒です。

例えば、仮にロックファイルにプロセスIDを書き込んだとしても、
1)プロセスIDを読み取り 2)該当プロセスが存在しないことを確認して
3)ロックファイルを削除する という一連の操作はatomicに行う必要があります。

http://www.din.or.jp/~ohzaki/perl.htm#File_Lock

これじゃだめなの？
ロックファイルの「削除」がない、うまいロックだと思うんだけど。

デフォルファイルの損失の場合さえなければロックとしてはかなりいい感じだと思う。

> http://www2q.biglobe.ne.jp/~terra/cgi/lockfile.htm
こんなアホなとこ紹介してはいけない。大崎＠リコー氏のところを見よ。
あとはシグナルについて言及してあれば OK なのだが…。

問題ないロジックだと思います。私の頭では穴が見つけられませんでした。
一定期間でプロセスが終了するという保証はないので、
ロックファイルの命名規約を拡張して
プロセスIDもチェックした方が良いと思います。

ただ、flockが使える状況なら、常にflockを使ってください。
ファイルI/Oによるロックは、I/Oアクセスのコストがかかるうえ、
ポーリングによる待ちであり、flockに比べるとデメリットばかりあります。

ネタじゃないよね…？
本気ならそこのは駄目ロックだと思うのですけど。

まずロック確認から自身のロック開始までがいくつもステップを踏んでるので遅いです。
確認から開始までの間に割り込まれるスキが symlink などに比べて大きい。

>>61 のURLのことですが駄目ロックは言い過ぎか…訂正します。
でも１．〜３．は納得いかないなあ。
ロックに挑戦してタイムアウトしても書込むようにしてあれば symlink じゃなくても欠点になるでしょ。

> http://www.din.or.jp/~ohzaki/perl.htm#File_Lock
に記載されたロジックに関する話をしています。

ロックのために20行も書くんなら(ライブラリも含む)
たまに壊れるかもしれないけど許してねとflockで済ましちゃうな。
守ろうとするデータにどれほどの価値があるか次第だっつーのは
セキュリティにも通じる。

flockが使える環境であれば、
flockを使ったロックは *常に* 正しく動作することを
OSが保証しています。

たまに壊れるのは、実はflockが使えない環境であるか、
スクリプトにバグがあるかのどちらかです。
(OSにバグがある場合もないではないが、今となっては稀)

うーーん。それって「使えるところでは使える」っていうトートロジーだよね。
言わんとするところは分かるような気がするが。
NFS環境でないUN＊X系では使えると思っていいのかな。

つーか、そんなに真剣に何を排他制御したいのかね? >>68

symlink/rename/mkdirがOS依存も少ないし安全っぽいのは理解に難しくないが
それはロック自身が安全だってだけで、アンロック忘れのリスクが増えるんだよね。
それで20行だかのルーチンを書かなきゃならん。

それって頑張るポイントが違うと思うなあ(俺はね)

flockなら3行以内だぜ?　しかも67の言うとおり、今時失敗することは実は有り得ない。
まあ御客には釘さしとかないと、本当に壊れたときが面倒だからさ。

1バイトも漏らせません!!デッドロックも起こせません!!てなら
もうRDBとSQLでしゃべるしかないと思うよ。

自分が使ってたアクセスカウンタでは flock だと頻繁に壊れてた。
二重化してたけど月一くらいで飛んでしまってた。
symlink にしてからは今のところログが飛ぶことは起きてないんで継続して利用してます。
まあ他の人の環境でどうか、って言われるとわからないのだけど。
しかし >>61 のサイトはアンロック処理のリスクに加えて open なんか使ってるし…。すごいね。

rename はNFS環境だとAtomicであることを保証されてません。

さらにNFSのバージョンが2以下だと delete＠｀ create もAtomicで
あることを保証されてません。

プロバイダの環境だと使えない手かもしれないけども
ロック専用の小さいサーバープロセス使うのが楽だよ
クライアントが死んだときとかのロック状態残らないしさ
サーバープロセスはポート番号が重複しないからSingletonは
保証されるし
あとは cron に サーバープロセスを監視するWatchDogつけとけば
まぁ安心

相手がどんな環境かなんてことも考慮する必要がない。
flockと違って、ロック中にいつ、どのファイルをopen＠｀closeしても良い。

俺なら59のを使うよ。
一旦書いたらそれで終りだしな。べつに苦労ではない。

いや俺は、ロックの安全さと、アンロックの安全さと、
記述量のバランスが肝心だと言いたいだけなんだけどね。

59のロック関数を信用するなら使えばいいさ。

話は違かもしんないんだけど、カウンター程度のモノ作るなら
ファイルを二つ用意しといて、それに交互に書き込んでいくっ
て方法もあるよ。たしかハッカージャパンかなんかにソースが
出てた。

この方法だと二つファイルを読み比べて数が大きい方を良しと
するから、片一方が死んじゃってても、まぁ、完全に正確にと
はいかなくてもクリアされちゃう事はない。

一時期に膨大なアクセスがある、某大企業のリクルートのペー
ジのカウンタ作ったとき、いろいろ試してみたけど、なんか、
この方法が一番安心なように思えた。問題なく動いてくれたし。

なんか、こう柔軟性というか、ある程度のテキトーさがあるほ
うがイイんじゃん。

>48=75
だから使うって言ってんだろ、ボケ

>>48
文句を言わずにお前が完璧な排他制御のコード書けや。（'Д'）y ─┛~~

で、どの方法がいいんだ？

だから俺もドーゾって言ってるんだけど >>77

どさくさにまぎれて他力本願だなお前 >>78

>48
てめーごときが何を偉そうに「ドーゾ」だ。逝って良し！

ドーゾは偉そうじゃないだろ。面白いなお前 >>81=77

あや、御名前まちがっちった　>>82
はいツッコミドーゾ >>77

>>71
> rename はNFS環境だとAtomicであることを保証されてません。

これが気になったのでちょっと調べてみましたが、よくわかりませんでした。

仕様では、NFSサーバ側のrename操作はatomicであることが保証されています。
(新しいファイルと古いファイルの両方からlinkされている
過渡的な状態は存在しない)
しかし、NFSクライアント側の実装をみると、
lookupとrenameがatomicではありません。
また、renameがidempotent(等冪、同じ操作を何度行っても結果が変わらない)では
ない事に対処するkludgeが入っているために、
どうやら、複数のNFS clientにまたがったプロセスが
同時にrenameシステムコールを発行した場合、
一つのプロセスだけが成功することは保証されていないようです。

でも、rename要求を出すのが同一ホストだと限定すれば、
atomicであるように思えます。(client側のvnodeレベルで排他されるので)

もしよかったら、教えていただけるとありがたく。

>48
消えろボケ

ボケの次は何かな? >>77

>48
消えろっつってんだろ、ボケ

不毛だからやめとけ
と言いつつ 48 同様様子を見たくもある。

メッセージ固定になっちゃったね　>>87
オートボケスクリプトかなんか自作したんだ。凄いじゃん。

略すとオーボケか…

>>84
質問の途中で邪魔してすまなかった。

本題については俺は知らないです。つーか、flockで心中な気分だし。

なぜflockを嫌うんだ、ボゲェ！
ってことですか？

いや?俺の意見だけ聞いてもらっても困るんだが、
俺個人は要するにボゲェ以外は1と同意見。

84 については俺もわからん。すまん。
これはもはや UNIX 板の管轄ではなかろうか。

俺的にボケはソフトではなくそれを使い切れてない人間達にだと思うが。
俺も含めてな。

あのー。すみません、こういうサポート↓してるところはどうなんでしょう。
まだお金は払ってないんですが、明日が支払いの締め切りで。

---
CGI等でご利用される場合は、解除または、ロックの
使用していないスクリプトをご利用くださいますよう
お願い致します。

ロックに関しては、さまざまな意見がございますが、
当方で利用しておりますCGIでもロック機能をOFFにして
動作させていますが、支障なく動作していますので
大丈夫かと思います。

「まだ問題出てないからロックしない」なんてところやめとけ。
俺以上の素人か。
ログ飛んでも気にしないのなら好きにすればいい。

壊れる証明はすぐにでも出来るが、壊れない証明は不可能。

初歩的な質問で申し訳ないのですが、21のコード
>open(FILE＠｀ "+<$file");
>eval{ flock(FILE＠｀ 2); }
>#
># ここに読みコード
-----以下省略-----
これで、最初にロックをしようとして、そのファイルが他の
プロセスでロックされてる時はロックが解除されるまで待つと
思うのですが、いったいいつまで待つのでしょうか？
ちょっと気になったのですが、調べてもわからなかったので
教えていただければ幸いです。

>>98
ロックが解除されるまでいつまでも。
もしかしてタイムアウト処理がしたいとか？
ならば flock(FILE＠｀LOCK_EX|LOCK_NB) で。詳細は略。

99さんありがとうございます。
別にタイムアウト処理をしようと思った訳でもないです。
単純にどうなるのかな疑問に思っただけですの。
詳細は自分で調べてみます。
それと、ついでなのですがもう一つ疑問に思う事があるのです。
上のコードでもそうですし他の解説もたいていそうなってるのですが、
openしてからflockするのはなんか不自然に感じます。
まず、「今からファイル開けるけどロックかかってないかーー？」
「かかってないなーー。よし、ロォーーーック！」
「さてと、邪魔者は来れなくしたからゆっくり料理したろ。オーープン。」
って感じになるのが普通のような気がしたので。なんか不思議な気がします。

>98

あるプロセスがあるファイルにロックをかけている間、ほかのプロセスのそのファイルへのロックは失敗します（ﾜﾗ

ロックは、そのファイルにアクセスするどのプロセスもロックをかけてからアクセスしようとする場合に限り、効力をもちます（ﾜﾗ

ロックをかけないでアクセスすることは、可能です（ﾜﾗ

そのときアクセスは排他されません（ﾜﾗ

ちなみに open にロックをかける仕組みになってないのは、


書きこみだけにロックすること（つまり読みこみは自由）を実現するため（ﾜﾗ

むぎ茶さんありがとうございます。参考になります。
それと、openとflockの順番なのですがさっきお風呂に入ってて
ふと思ったことがあります。
flockってファイルをロックするというより、ファイルハンドルを
ロックするような気がします。だから先にopenしておいて
そのファイルハンドルをロックする・・・というので正しい気が
してきました。ちがうのかな？

榕

いいスレだ

ログファイルの追記の時は、
ファイルロックしなくても問題ないって本当ですか？

open LOG＠｀ '>>hogemax.dat' or 逝く;
printf LOG "%s＠｀%s\n"＠｀ 時間＠｀ リモホ;
close LOG;

>>106
2つのプロセスが同時に追記しようとしたら競合しない?

>>107
えっと、>>52 によると、
＞ただ、アクセスログならば追加書き込みするのが普通だと思いますが…
＞追記の場合もsyswriteすれば、flock不要です。
だそうです。詳しい方説明きぼんぬ。

そうだとしても106はsyswriteを使っているように見えない。

fwrite() で追記した場合のみ大丈夫で、
fprintf() ならダメかもしれないということですか？

追加。
Perlは無視して答えてくれると有り難いです。

>>110
　内部でwriteシステムコールを複数呼ぶ可能性があるとその間に割り込まれるかもしれないということ。
syswriteならwriteシステムコールそのものだから問題なし、ってことじゃない?
　ただ俺はUNIXの追記モードについてはよく知らないんだが
1. プロセスAがオープン
2. プロセスBがオープン
3. プロセスAが書き込み
4. プロセスBが書き込み
みたいな順序になっても4.が3.を上書きすることはないの? ないならflockは不要だと思う。
>>111
　syswriteに対応するのはCではwrite。fwriteじゃないよ。

> みたいな順序になっても4.が3.を上書きすることはないの? ないならflockは不要だと思う。
オフセットはファイルディスクリプタ毎に保持されてるので、上書きする。

>>113
普通の書き込みモードならそうだと思うけど、追記モードって書き込みのたびに末尾にシークするでしょ?
「末尾」の位置に関する情報もファイルディスクリプタごとに独立しているの?

>114
114が正しい。
鬱だ氏脳

>>112-115
『追記モード』でファイルを開いた場合は、
write(2)やfwrite(2)やfprintf(2)などを使うと、
１．ファイルの末尾へ自動シーク
２．追記処理
この２つが atomic に行われると考えて宜しいですね？
皆さん、ありがとー☆

>>116
writeは2(システムコール)だが
fwriteやfprintfは3(libc)だろ? (つまりatomicとは限らない)
112の最後の
>syswriteに対応するのはCではwrite。fwriteじゃないよ。
読んだか?

>>117
＞fwrite()やfprintf()は atomic とは限らない。
これが知りたかったんですわ。どうもありがと☆

見つけた。
O_APPEND：ファイルを追加(append)モードでオープンする。それぞれの write の前に lseek を行ったかのように、ファイル・ポインターをファイルの最後に移動する。

flockが使えないサーバーとは、
たとえばどんなの？
FreeBSDならOKとかなるのですか？

FreeBSDでもNFS上はだめだろう

open(FILE＠｀ "+<$file");
flock(FILE＠｀ 2);
seek(FILE＠｀ 0. 0);
truncate(FILE＠｀0);
print "aaaaa";
truncate(FILE＠｀ tell(FILE));
close(FILE);

ファイル書き込む時truncateってした方が良いの？？
意味無い気がすんだけど・・・。
（バカで誤麺ね・・誰か教えて。。）

ほら、それ、読み書き両用でひらいてるからさ。

>>122
ログファイルが追加されていくだけなら問題は無いが、普通ある程度の量が溜まったら
古いものから消していくでしょ？　あるいは掲示板の特定の発言を削除するとか、
そういう風にログの分量が減ると末尾にゴミが出るのだ。
truncateを使えば大丈夫。
それと余談だが
tell(FILE) は　単純にtell だけでＯＫ。この場合ね。

読み書き両用はあんまり使わない方がいいと思う。
必要な時に一気に読み込み（メモリを喰うがこっちのが処理しやすい）、
短時間で処理を終えたら一気に書き込むのが自分は好きだ。

末尾にゴミですか、勉強になりました。
ありがとうございます。

って事は書き込み専用でやれば、truncate(FILE＠｀0);
とかも要らないのかな？

なるほど・・・。

flcok() ?

>>126
ココまでレスついて、誰も指摘しなかったのに・・・（爆）

NFS以外のflcok()が使えない場合ってありますでしょうか？

よくわかんないけど、flcok()はどこも使えないのでは？

open(IN＠｀"+< $file");
eval {flock(IN＠｀2);};
$temp = <IN>;
truncate(IN＠｀0);
seek(IN＠｀0＠｀0);
close(IN);
いつも使っているこれは、無駄だったのか・・・

flcok()は、使えねぇよね（笑）

とりあえず自分のサーバでflockがOKか調べるなら

while(いっぱい繰り返し){
open(IN＠｀"+< $file");
flock(IN＠｀2);
$n=<IN>;
$n++;
seek(IN＠｀ 0＠｀ 0);
print IN $n;
truncate(IN＠｀ tell(IN));
close(IN);
print $n;
}
print $n;
こんな感じで最後の$nが数字的に合ってればだいじょぶかな？駄目？(^^;

>>125
open(FILE＠｀ ">$file");
で新規空ファイル作成＆書き込みをしていればtruncateは不要です。
というか >>122の処理って、よく見ると結構すごいですな・・・

間違ってました。気にしないで。

>>124
読んでから書くまでの間の同期はどうやって取るんだ?

>>132
あんたのほうが凄いよ。そんな恐ろしいやり方を勧めないでくれ。
これ見ろ。
http://www2.kiwi-us.com/~j_n/perl/flock.html

>>134＠｀135

124でも132でもないけど、
ロック用のファイルを準備すれば済む話でしょ。
#区間ロック、、と呼んでいいものか。

そこまでしてtruncate使いたくないか？って話でもあるけど
ま、仕様によっちゃそっちのがいいでしょ。

ここのロック説明読んでるとだんだんよさげな気分になるんだけどどう？
http://www.itboost.co.jp/php3/file.php3

ちなみにPHPでの話です。

って事は、
＞必要な時に一気に読み込み（メモリを喰うがこっちのが処理しやすい）、
＞短時間で処理を終えたら一気に書き込むのが自分は好きだ。

こんな処理をしようとして、読み込み時にflockしてないと
flockされてるけど書き込み中の空fileを見事に読み込んで
ログが消失するわけですな。

ってか俺、今まで読み込み宣言って使ったこと無かったよ(笑)
ヤバイヤバイ・・・。

ん？　なんかツッコミがいくつか入ってますな・・・
とりあえず俺はflockなんて使わない派（rename）。

ログの同期（？）は、まあ仮に掲示板としておきましょうか、
表示用に１回読んでおき、書き込みを追加する時には
「もう１回最新のファイルを読み出して追加して書き込む」
とやってるけど。「　」の部分はファイルロックかけてる。
これでファイル消失はないはずだけど？
根本的に問題があれば分かりやすく説明お願いします。
（２回読んでいるのは無駄だとかそういうのはナシね）

>>135
何が恐ろしいの？　どこを見せたいのかよく分からんので噛み砕いて教えて。

>>140
表示に失敗するのはロックしてても失敗するだろうからOKって事？

>>141
なんで表示に失敗するの？
１秒間隔くらいで最低３トライくらいは待つよ。
そうすればロックが解けて表示されるし。

ていうかスマソ。
読んで表示する時は当然読むだけで、、
書き込む時は先に「ロック状態でファイルを読んで追加し書き込み（ >$file ）」してから
ログ表示するから２回読んでないね。
この考え方だとtruncateは要らんでしょ？

つーか、renameを使う理由がよくわからない
いちいち、flockと同じ機能をperlで実装すると言う発想が無駄。
おそらく、flockが何やっているか想像がつかないから、
不安なんだろうね。

それはマジレスなんだろうか・・・（ごめん、苦笑

俺がflockの意味を分かってなくて、頑張って他の方法を試そうと
していると思いたいようだけど大外れです。
ここの過去ログを読み返せば何度か話題になってるけど、
サーバによってはflockは効果がないの。
あたかも「flock成功しました」みたいな感じでサラッと動いて、でもログは壊れてる。
だから代用を考えなくてはいけないってわけです。

自サバでflockのチェックすれば良いだけでは？？
駄目なサーバの方が多いって事でもないでしょ？

>145
断言するけど、君がflockの仕組み理解してないだけよん
つまり、スクリプトバグってるだけ。
サーバーによってflock使えないのは当たり前だし。
処理によっては有効でないのも当たり前。（普通無いけど）
そんなのは仕様だろ？
ただ、ほとんどが機能するサーバーなんだから、
そんなイレギュラーなサーバーのために、
そこまで汎用性持たせる必要があるのって事だよ。

ただ、flockが有効な時にflock使わないのは頭悪すぎ。
OSレベルで提供している機能なんだよ？
OS信用できないなら、君のCGIはどこで動かすんだよﾜﾗ

ちなみに、実例挙げれば、一つのDBMをflockで排他する
スクリプトで、ピーク時に1時間に2000回更新。10000回の読みこみ
を行うサイトで1年間運用しているけど、壊れたことなんかねーよ。
OSは、linuxのredhat7.xだけど。

つーか、OS疑う前に、君のスクリプト疑えよってのが、
客観的な意見なﾜｹ。
端から見るとﾅﾝｾﾝｽﾃﾞ失笑ものなわけよ。

で、flock以外で壊れない方法見つかったの？ﾜﾗ＞145

>>146
俺が使っているサーバではflockは使えませんでした。
だから必要に迫られています。

>>147
釘を刺しておけば良かったかな？
問題のすり替えはしないでくれと‥‥。
つまり、俺のスクリプトのロジックがおかしいという前提はありません。

同じスクリプトをflockが効くサーバで動かしたところログ消失はなかったからね。
もちろん数千回を超える耐用試験までやったわけじゃないけど。
逆にflockが効かないサーバでは、せいぜい４人くらいしかいないチャットなのに
毎日のようにログが消えてたよ。

で、煽ってくれたから軽く煽り返しておくと、
思いっきり冒頭で断言しちゃったのはとっても恥ずかしいね。

結構flock壊れてるサーバって多いのかねぇ。。
レンタルやるなら治しておいて欲しいもんだね。
まあ、自サバなら自分でやればいいんだろうけど
ロックファイル使った方が手っ取り早いって話も・・・。汗

OSレベルって、べつにOSのシステムコールを
直接呼び出してるわけじゃないじゃん。
Perlの中で妙なこともやってると、誰かいってたような。

flockって、複数のファイル更新のとき
ファイル閉じる順番を注意するのが面倒くさくない？
（flockかけたファイルを最後に閉じなきゃならん）
何か良い方法あるのかなぁ。

バカ多すぎ

まさに、木を見て森を見ず、、、

精一杯の強がりだね。

誰が正しくて誰が間違っているのか。
頭のいい人教えてください。

でもマジレスｸﾝと145さんは答えないでネ！

>153
それは誰に言ってるの？

あんたが当事者（マジレスｸﾝ or 145）なら
それで良いと思うけど、
部外者にはわかんないよ。

152に対して言ってるんだったら
153=145の自作自演でしょうな。
紛らわしいので以後は名無しさんで
書き込まないで。

>>155
うん、>>153は俺が書いたものです。
別にコテハンじゃないし、145って名前で書くと本筋と違う争いが発展するかと
思ったから。
でも逆効果だったようだね、スマソ。
とりあえずマジレスｸﾝに伝わればよかっただけだし、部外者は気にしてなかった。

ただこのまま俺が145で何か書いても、彼は問題をすり替えるだけじゃないかな？
そういう意味では不毛だから本当はもう名無しに戻りたいんだけど。

問題のすり替え？
んじゃ、君の問題としていることって何なの？
さっぱりわからん。

今過去ログよんだけどやっぱり、、、

>読み書き両用はあんまり使わない方がいいと思う。
理由を教えてよ。
妄想でも構わないから。ﾜﾗ

>必要な時に一気に読み込み（メモリを喰うがこっちのが処理しやすい）、
>短時間で処理を終えたら一気に書き込むのが自分は好きだ。
君の頭の中では短時間なんだろうね。
久々ﾜﾗﾀ
すげー文学的表現だよ

ちょっと暇っだったから煽っただけで悪気は無いの
ｶﾞﾝﾊﾞｯﾃﾈ

ageちゃった。
ｺﾞﾒﾝﾈ

>156=145
素直でよろしい。応援するよ。

まあいいやろ、使える所はflockで
その他の所は好きにロックすればええってことやね？
まあ、flockつかえる所で使わんのは、あほらしいって事でしょ。

で、ロック中だった場合の処理って
みんなあまり書かないけど

flock(FH＠｀LOCK_EX)||print "ロックされてるぞ〜";

って感じでできるん？？

それと・・・NT、OS/2は、強制ロックだから
ロックすればflock無しでも書き込めないらしいです。

もうマジレスｸﾝはレスしないだろうけど、一応。
ちとキツい表現があるのはスマソ＞部外者の方

＞マジレスｸﾝ

＞んじゃ、君の問題としていることって何なの？
俺は何も問題としてないけど、君が>>144でよく分からんこと言ってるから
・・・っていうか俺の書き込みに一言いいたかった（からみたかった）んでしょ？
それにおとなしめに答えたら煽られたのがそもそもの始まりだよ。

要するに俺はflockが効かないサーバも使っていて、本来ならちゃんと
flockが効くのかどうか確かめる必要があったのだろうが、ここを読むまで
そこには思い至らず、flockは使えんと判断し、renameによる手法を知ったので
それを好んで使うようになっただけだ。
むしろflockが使えることを保証しているサーバでflockを使う方が簡単でしょ。
でもrenameで自分には必要充分なロック効果が得られているので敢えてflockに
戻るつもりはないってこと。
AN-HTTPD用にeval使うのも正直ウザいし。

でさ、俺のスクリプト見たわけでもないのに「スクリプトがバグってる」とか決めつけて、
それは「言うに事欠いて」ってやつだよ。
詳しい理屈までは分からんが、実際にflockが効かないもんは効かないんだ。
もしそういうサーバを使うことになったら君はどうするのかね？　んん？
強いて言うならこれがさっきから君のすり替えている「問題」。

もういっちょ、続き。

＞>読み書き両用はあんまり使わない方がいいと思う。
＞理由を教えてよ。
＞妄想でも構わないから。ﾜﾗ
こんなこという奴だから相手にしなければよかったな〜。
ファイル末尾のゴミ処理にtruncateを使わないといけなくなるでしょ？
俺のスクリプトの書き方の好みだと言えばまあそれまでだが。
初心者の頃ゴミが出現して苦戦した記憶があるし、トラブルのもとになるくらいなら
ロジックごと変えたほうがいい。
逆に君は読み書き両用を推奨するようにも受け取れるけど、その理由は言える？

＞君の頭の中では短時間なんだろうね。
＞久々ﾜﾗﾀ
＞すげー文学的表現だよ
ファイルロックしてから無駄なステップを費やさないってことだよ。
何がそんなに笑えるのか分からない。


>>160
ありがとうございます。
自分は自作自演とか騙りとか大嫌いなんで、
そういう風に思われてショックを受けると同時に深く反省しました。

　124から

>「もう１回最新のファイルを読み出して追加して書き込む」
>とやってるけど。「　」の部分はファイルロックかけてる。

ってのがとても読み取れなかったんだよ。ｽﾏｿ
　最初の(flockしない)読み取りは表示とか壊れてもいいもの以外には使わないわけね?

>AN-HTTPD用にeval使うのも正直ウザいし。

　それは同意。ウザいというかflock使うならevalするなんて中途半端はよしたほうがいい。理由はがいしゅつだから繰り返さないけど。

>>164
＞最初の(flockしない)読み取りは表示とか壊れてもいいもの以外には使わないわけね?
その通り。読む時は読むだけ。
説明を大幅に端折ってしまったので誤解を招きました。こちらこそスマソ。
要はロジックは自分で考えてね〜ということでして、当然あの書き込み方そのものは
使う人次第でとても怖いものになるでしょう。

＞ウザいというかflock使うならevalするなんて中途半端はよしたほうがいい。
以前どこかでflockにevalかけると良くないって読んだ気がする。
気のせいかもしれないけど。理由はよく分からない・・・。
renameだととりあえず自分が使ってるサーバすべてで効果が期待できるんで
俺はたぶんこれからもそうやって行きます。

>145
名無しに戻ってよろし。

> 150
これか?

http://tako.2ch.net/test/read.cgi?bbs=perl&key=962797645&st=296&to=296