検索コマンド：-sizeアクション

GNU find のマニュアルページは次のとおりです。これはGNU findに固有のものであり、他の実装は異なる場合があります。下記をご覧ください。

いつものように、+と-の接頭辞は、より大きいとより小さいことを示します。つまり、n 単位の正確なサイズが一致しません。寸法は次の単位に丸められます。したがって、同じでは-size -1Mありません-size -1048576c。前者は空のファイルのみと一致し、後者は0〜1,048,575バイトのファイルと一致します。

質問：

さて、それでは-1Mは0Mに丸められ、-2Mは-1Mに丸められるようですね…？

-sizeいいえ。丸め条件は制限ではなく、ファイルサイズ自体です。

1234バイトのファイルと-size -1Mコマンドをインポートします。ファイルサイズは、説明書に記載されている最も近い単位（ここではMB）に丸められます。 1234B - > 1MB。-size -1M要件を満たしていないため適していません。未満1MB（丸め）。したがって、実際には空のファイルのみが返されます。-size -1xx

上記のファイルは、-size 1M丸め後のサイズが正確に1 MBであるため、一致します。 （サイズが1Bから1048576Bのすべてのファイルと一致します。）一方、-size 1k1234Bは2kBに丸められるため、一致するものはありません。

条件では、数字の前後に丸め-動作+とは関係ありません。

丸めの問題が発生しないように、常にサイズをバイト単位で指定すると便利です。-size -$((1024*1024))cサイズが1MB（または必要に応じて1MiB）未満のファイルを確実に見つけます。たとえば、範囲が必要な場合は、( -size +$((512*1024-1))c -size -$((1024*1024+1))c )[512kB、1024kB]内のファイルを使用できます。

これに関するもう一つの質問は次のとおりです。「find -size -1G」がファイルを見つけられないのはなぜですか？

関連質問で言及されているGilles実はPOSIX は次のように指定します。 -size Nas は 512 バイトのブロック単位のサイズを表します (上記のように丸められます: "ファイルのサイズ (バイト単位)、512 で除算し、次の整数に丸められます")。 asはサイズ（バイト単位）を表します。どちらもオプションのプラス記号またはマイナス記号が付属しています。他のものは指定されておらず、すべての実装が他のプレフィックスを認識していないか、GNU findのように丸めます。-size Ncfind

MacでBusyboxと* BSD findでテストした結果、より合理的に感じられるようにサイズ指定子を使用して条件を処理するようです。つまり、-size -1k0 から 1023 バイトまでのファイル一致、 と同じ-size -1024c、-size -1M== も同様です-size -1024k(Busybox のみ) c、bとk)。その後、POSIXテキストで言うのとは異なり、Busyboxはブロックで指定されたサイズに対して丸められないようです。

したがって、YMMVもサイズをバイト単位で維持する方が良いかもしれません。

-atime-mtimeと条件にも同様の問題があります-ctime。

-atime n
ファイルはn * 24時間前に最後にアクセスされました。 findが24時間前に最後にファイルにアクセスした期間を計算すると、小数部は無視されます。したがって、一致するには、-atime +1ファイルに少なくともアクセスしたことが必要です。二つ数日前。

同様に、-amin +$((24*60-1))この機能を使用して、少なくとも24時間前に最後にアクセスしたファイルを見つけるのが簡単になります。 （1分に増やすと外れません。）

また見なさい:find -mtime +1が2日前のファイルのみを返すのはなぜですか？

これは正常ですか、それとも私が何か間違っているのですか？ -sizeパラメータの正確な動作は何ですか？

これはGNU findの動作の面では「正常」ですが、完全に合理的ではありません。混乱しているのは間違っているのではなく、find混乱しているだけです。