3/21 22時頃: 質問編へのリンクを撤去し、タイトルを変更しました。(元のタイトルは「【謎】本当にあったfindコマンドの怖い話【解決編】」) 昨日のエントリについて、実験にしてはケースが雑だったので再検証していきます。 【謎】本当にあったfindコマンドの怖い話【おもしろ現象】 - くんすとの備忘録 ちなみにモチベーションは「問題を回避したい」ではなく「この現象の原因を知りたい」です1。 よろしくお願いします。 現象からしてfindコマンドが処理中に書き換えられたファイルを読み込んでいるのは明白です。 少しずつ仮設を立て見ていきましょう。 まぁまぁお付き合いください。 検証ケース ケース1: 10万ファイルで実行 ケース2: パイプを使わずfindコマンド一発にし、100万ファイルで実行 ケース3: ケース2を10万ファイルで実行 ケース4: ケース2を15万ファイルで実行 ケース1

※質問受付は終了しました。(3/22) 先にまとめ リネームではinode番号は変わらないけどエントリの位置が変わることがある。 これが一番知りたかった情報。でも文章では理解したけど、検証コードはどう書けばいいかわからん… readdirはアトミックじゃない。読み込み中にエントリ情報が変われば次の読み込みに影響する。 man にも「readdir()は非スレッドセーフです」って書いてある。 fts_readは実行時にreaddirの結果を10万件(ずつ？)キャッシュしていて、途中(たぶん10万件)まではエントリの変更の影響を受けないっぽい。途中からreaddirと同じことが起こる。 ソースコードの斜め読みと挙動を観察した限りそんな感じっぽい。厳密に裏取りしたいけど疲れた。 findコマンドは readdir ではなくそのラッパーの fts_read を使っているので、 fts_read と

3/21 22時頃: 質問編へのリンクを撤去し、タイトルを変更しました。(元のタイトルは「【謎】本当にあったfindコマンドの怖い話【未解決→解決済み】」) 要約 100万個のファイルに対して、find コマンドから始めて mv コマンドでファイル名を変更するワンライナーを実行すると、 mv コマンドが約158万回実行されました。 背景 これは、Software Design 2018年4月号 Software Design 2018年4月号 の「シェル芸人からの挑戦状」の記事執筆中に遭遇した不思議な現象です。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を

最近のFreeBSDには「bsdinstall」というべんりツールが付属していて、どれくらい便利かっていうとワンライナーでOSのインストールが完了するくらい便利なのです。 環境 Windows7 64bit VirtualBox インストールメディア：FreeBSD-10.1-RELEASE-amd64-disc1.iso 手順 ①インストールメディアからブートします。②「2. Boot Single User」を選択します。 ③/bin/shのままログインし、おもむろに以下のワンライナーを入力します。 mdmfs -s 100m md1 /tmp && printf 'PARTITIONS=ada0\nDISTRIBUTIONS="base.txz kernel.txz"\n'>/tmp/a && bsdinstall script /tm