なぜ心を包むのに苦労しています find ファイルの変更回数をそのように解釈します。具体的には、なぜ -mtime +1なのかわかりません 48時間未満のファイルは表示されません。
テストの例として、変更日が異なる3つのテストファイルを作成しました。
[[email protected]obox findtest]# ls -l
total 0
-rw-r--r-- 1 root root 0 Sep 25 08:44 foo1
-rw-r--r-- 1 root root 0 Sep 24 08:14 foo2
-rw-r--r-- 1 root root 0 Sep 23 08:14 foo3
次に、 -mtime +1を使用してfindを実行しました 切り替えて、次の出力を取得しました：
[[email protected] findtest]# find -mtime +1
./foo3
次に、 -mmin +1440を使用してfindを実行しました 次の出力が得られました：
[[email protected] findtest]# find -mmin +1440
./foo3
./foo2
findのマニュアルページによると、これは予想される動作であると理解しています。
-mtime n
File’s data was last modified n*24 hours ago. See the comments
for -atime to understand how rounding affects the interpretation
of file modification times.
-atime n
File was last accessed n*24 hours ago. When find figures out
how many 24-hour periods ago the file was last accessed, any
fractional part is ignored, so to match -atime +1, a file has to
have been accessed at least two days ago.
しかし、これはまだ私には意味がありません。したがって、ファイルが1日、23時間、59分、59秒前の場合、 find -mtime +1 それをすべて無視して、1日、0時間、0分、0秒のように扱いますか？その場合、その1日は技術的に古くなく、無視されますか？
計算しません…計算しません。
承認された回答：
簡単な答えは、おそらく、findの実装はPOSIX / SuS標準に準拠しているということです。これは、このように動作する必要があることを示しています。 SUSv4 / IEEE Std 1003.1、2013 Editionからの引用、「検索」：
-mtime n
ファイルの変更時間を初期化時間から差し引いたもの
を86400で割った値（余りは破棄されます）がnの場合、プライマリはtrueと評価されます。
（そのドキュメントの他の場所では、 n 実際には+nにすることができます 、および「より大きい」としてのその意味）。
なぜ標準がそのように動作するのかについては、プログラマーは怠惰であるか、それについて考えていなかったと思います。Cコード（current_time --file_time）/ 86400 。 C整数演算は、余りを破棄します。スクリプトはその動作に応じて開始されたため、標準化されました。
仕様の動作は、変更日（時刻ではなく）のみを保存する架空のシステムにも移植可能です。そのようなシステムが存在したかどうかはわかりません。