【謎】本当にあったfindコマンドの怖い話【検証編】
3/21 22時頃: 質問編へのリンクを撤去し、タイトルを変更しました。(元のタイトルは「【謎】本当にあったfindコマンドの怖い話【解決編】」) 昨日のエントリについて、実験にしてはケースが雑だったので再検証していきます。 【謎】本当にあったfindコマンドの怖い話【おもしろ現象】 - くんすとの備忘録 ちなみにモチベーションは「問題を回避したい」ではなく「この現象の原因を知りたい」です1。 よろしくお願いします。 現象からしてfindコマンドが処理中に書き換えられたファイルを読み込んでいるのは明白です。 少しずつ仮設を立て見ていきましょう。 まぁまぁお付き合いください。 検証ケース ケース1: 10万ファイルで実行 ケース2: パイプを使わずfindコマンド一発にし、100万ファイルで実行 ケース3: ケース2を10万ファイルで実行 ケース4: ケース2を15万ファイルで実行 ケース1
【謎】本当にあったfindコマンドの怖い話【質問編】
※質問受付は終了しました。(3/22) 先にまとめ リネームではinode番号は変わらないけどエントリの位置が変わることがある。 これが一番知りたかった情報。でも文章では理解したけど、検証コードはどう書けばいいかわからん… readdirはアトミックじゃない。読み込み中にエントリ情報が変われば次の読み込みに影響する。 man にも「readdir()は非スレッドセーフです」って書いてある。 fts_readは実行時にreaddirの結果を10万件(ずつ？)キャッシュしていて、途中(たぶん10万件)まではエントリの変更の影響を受けないっぽい。途中からreaddirと同じことが起こる。 ソースコードの斜め読みと挙動を観察した限りそんな感じっぽい。厳密に裏取りしたいけど疲れた。 findコマンドは readdir ではなくそのラッパーの fts_read を使っているので、 fts_read と
install(1)コマンドが便利だった件
はじめに install(1)という、cpとmkdirとchmodを同時に行うような便利コマンドがあることを知りました。 (忘れちゃいましたが、何かのMakefileを見ているときに存在に気付きました) これを使うと、プロビジョニングなどのスクリプトが簡潔に書けるようになりそうです。 ……というわけで使い方のメモがてらまとめてみます。 manの内容まとめ installはBSD版とGNU版があるようですが、ここではGNU版について書きます。 BSD版ではいくつかのオプションが使用できません。(-D はなかったと思う) ちなみにmacの場合は標準でBSD版のinstallが入っており、Coreutilsを入れるとGNU版のinstallが使えるようになります。 4種類の使い方 install [OPTION]... [-T] SOURCE DEST SOURCEをDESTにコピーする。-Tを
BATファイルで、ロックファイルを使った排他制御を行う
これは、コマンドプロンプト(cmd.exe) Advent Calendar 2015 - Qiitaの20日目の記事です。19日目は @nmrmsys さんの “Tee for ToeKick 実行コマンドラインまで含めてログファイルに出力するコマンド” でした。 残りは全部自分です。最後まで駆け抜けるよ！※Windows 10 Home 64bit 搭載のcmd.exeにて検証を行っています。 さてさて 今回はBATファイルにおける排他制御に関して書きますが、自分がやったことのある内容で、ということで、もうちょい範囲を限定します。 今回は**「2つのBATファイルの実行について、ロックファイルを使った排他制御を行う」**という内容で書きます。 挙動について 「処理1.BAT」と「処理2.BAT」の実行を排他制御します。 「処理1.BAT」が起動した直後に「処理2.BAT」が起動すると「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DockerでXサーバを動かしてGUIを直接表示する
