whyfind
はファイルの変更時間と同じようにファイルの変更時間を解釈します。具体的には、-mtime +1
に48時間以内のファイルが表示されない理由がわかりません。
テストの例として、変更日が異なる3つのテストファイルを作成しました。
[root@foobox 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を実行し、次の出力を取得しました。
[root@foobox findtest]# find -mtime +1
./foo3
次に、-mmin +1440
を使用してfindを実行し、次の出力を取得しました。
[root@foobox findtest]# find -mmin +1440
./foo3
./foo2
Findのmanページによると、これは予想される動作であることを理解しています:
-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標準に従っているということです。POSIX/ SuS標準は、このように動作する必要があると述べています。 SUSv4/IEEE Std 1003.1、2013 Edition、 "find" からの引用:
-mtime n
ファイルの変更時間が差し引かれた場合、プライマリはtrueと評価します
初期化時間から86400で割った値(残りは破棄されます)はnです。
(そのドキュメントの他の場所では、n
は実際には+n
、および「より大きい」という意味)。
なぜ標準はそのように動作するはずだと言っているのかについては、まあ、プログラマーが怠惰だったり、それについて考えていなかったりして、Cコードを書いただけだったと思います(current_time - file_time) / 86400
。 C整数演算は残りを破棄します。スクリプトはその動作に応じて開始され、標準化されました。
仕様化された動作は、(日付ではなく)変更日付のみを格納する仮想システムにも移植できます。そのようなシステムが存在していたかどうかはわかりません。
-mtime
への引数は、ファイルの経過時間内の全日の数として解釈されます。 -mtime +n
は厳密により大きいを意味し、-mtime -n
は厳密により小さいことを意味します。
Bashを使用すると、より直感的に実行できることに注意してください。
$ find . -mmin +$((60*24))
$ find . -mmin -$((60*24))
24時間より古いファイルと新しいファイルをそれぞれ検索します。
(時間または分単位で解決したい場合は、-mtime
に小数引数を入力するよりも簡単です。)
24時間未満の端数は切り捨てられます!つまり、「find -mtime +1」は、2日以上前に変更されたファイルに一致すると言っています。
find . -mtime +0 # find files modified greater than 24 hours ago
find . -mtime 0 # find files modified between now and 1 day ago
# (i.e., in the past 24 hours only)
find . -mtime -1 # find files modified less than 1 day ago (SAME AS -mtime 0)
find . -mtime 1 # find files modified between 24 and 48 hours ago
find . -mtime +1 # find files modified more than 48 hours ago
以下はGNUでのみ動作する可能性がありますか?
find . -mmin +5 -mmin -10 # find files modified between
# 6 and 9 minutes ago
find / -mmin -10 # modified less than 10 minutes ago
-mtime N
は、日数[〜#〜] a [〜#〜]がを満たすファイルを意味します[〜#〜] n [〜#〜]≤[〜#〜] a [〜#〜] <[〜#〜] n [〜#〜]+ 1。つまり、-mtime N
は、[〜#〜] n [〜#〜]と[〜#〜] n [〜#〜]+ 1日前。
-mtime -N
は、年齢[〜#〜] a [〜#〜]が[〜 #〜] a [〜#〜]<[〜#〜] n [〜#〜]、つまり[〜#〜] n [〜#〜]日以内に変更されたファイル。直感的ではありませんが、-mtime +N
は、年齢[〜#〜] a [〜#〜]がを満たすファイルを意味します)[〜#〜] n [〜#〜]+ 1≤[〜#〜] a [〜#〜]、つまり、少なくとも[〜#〜] n [〜#〜]+ 1日前に変更されたファイル。
たとえば、-mtime 1
は、1〜2日前に変更されたファイルを選択します。 -mtime +1
は、少なくとも2日前に変更されたファイルを選択します。少なくとも1日前に変更されたファイルを取得するには、-mtime +0
を使用します。
「最後に変更されたのはn * 24時間前でした」という説明は概算にすぎず、あまり明確ではありません。
これらのルールを覚えにくい場合は、代わりに参照ファイルを使用してください。
touch -d '1 day ago' cutoff
find . -newer cutoff
(構文「1日前」にはGNU touch
が必要です。)
したがって、ファイルが1日23時間59分59秒前のものである場合、find -mtime +1はそれをすべて無視し、1日0時間0分0秒のように扱いますか?
はい。お気に入り man find
は、「小数部分は無視される」と述べています。 「1日、23時間、59分、59秒」を「24時間」で除算すると、1.9999になる可能性がありますが、.9999部分が削除され、突然ファイルが1日だけ古くなります。
-mmin、-aminなどを使用して、正確な結果を取得します