Saya berjuang untuk memikirkan mengapa find menginterpretasikan waktu modifikasi file seperti yang dilakukannya. Secara khusus, saya tidak mengerti mengapa -mtime +1 tidak menampilkan file yang berumur kurang dari 48 jam.
Sebagai contoh pengujian, saya membuat tiga file pengujian dengan tanggal modifikasi yang berbeda:
[[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
Saya kemudian menjalankan find dengan -mtime +1 beralih dan mendapatkan output berikut:
[[email protected] findtest]# find -mtime +1
./foo3
Saya kemudian menjalankan find dengan -mmin +1440 dan dapatkan output berikut:
[[email protected] findtest]# find -mmin +1440
./foo3
./foo2
Sesuai halaman manual untuk find, saya mengerti bahwa ini adalah perilaku yang diharapkan:
-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.
Ini masih tidak masuk akal bagiku. Jadi jika sebuah file berumur 1 hari, 23 jam, 59 menit, dan 59 detik, find -mtime +1 mengabaikan semua itu dan hanya memperlakukannya seperti berumur 1 hari, 0 jam, 0 menit, dan 0 detik? Dalam hal ini, secara teknis tidak lebih tua dari 1 hari dan diabaikan?
Apakah… tidak… menghitung.
Jawaban yang Diterima:
Yah, jawaban sederhananya adalah, saya kira, implementasi find Anda mengikuti standar POSIX/SuS, yang mengatakan harus berperilaku seperti ini. Mengutip dari SUSv4/IEEE Std 1003.1, Edisi 2013, “temukan”:
-mtime n
Utama akan dievaluasi sebagai true jika waktu modifikasi file dikurangi
dari waktu inisialisasi, dibagi 86400 (dengan sisa yang dibuang), adalah n.
(Di bagian lain dalam dokumen itu dijelaskan bahwa n sebenarnya bisa menjadi +n , dan artinya sebagai “lebih besar dari”).
Mengenai mengapa standar mengatakan itu akan berperilaku seperti itu — yah, saya kira lama di masa lalu seorang programmer malas atau tidak memikirkannya, dan hanya menulis kode C (current_time - file_time) / 86400 . C bilangan bulat aritmatika membuang sisanya. Skrip mulai bergantung pada perilaku itu, dan karenanya menjadi standar.
Perilaku spesifikasi juga akan portabel ke sistem hipotetis yang hanya menyimpan tanggal modifikasi (bukan waktu). Saya tidak tahu apakah sistem seperti itu pernah ada.