cap waktu, waktu modifikasi, dan waktu pembuatan file


105

Saya hanya tahu itu ls -tdan ls -fmemberikan berbagai penyortiran file dan subdirektori di bawah direktori.

  • Apa perbedaan antara cap waktu, waktu modifikasi, dan waktu pembuatan file?
  • Bagaimana cara mendapatkan dan mengubah informasi semacam ini dengan perintah?
  • Dalam hal informasi apa yang dikatakan orang bahwa sebuah file "lebih baru" daripada yang lain?
  • Apa jenis perubahan informasi yang tidak akan membuat file berbeda?

Sebagai contoh, saya melihat seseorang menulis:

Secara default, program rsync hanya terlihat untuk melihat apakah file berbeda dalam ukuran dan cap waktu. Tidak peduli file mana yang lebih baru, jika berbeda, ia akan ditimpa. Anda dapat meneruskan flag '--update' ke rsync yang akan menyebabkannya melompati file di tujuan jika mereka lebih baru dari file pada sumbernya, tetapi hanya selama mereka adalah jenis file yang sama. Artinya adalah jika, misalnya, file sumber adalah file biasa dan tujuannya adalah symlink, file tujuan akan ditimpa, terlepas dari timestamp.

Di samping catatan, apakah jenis file di sini berarti hanya file biasa dan simlink, bukan tipe seperti pdf, jpg, htm, txt dll?


Jawaban:


138

Ada 3 jenis "cap waktu":

  • Akses - terakhir kali file dibaca
  • Ubah - terakhir kali file diubah (konten telah dimodifikasi)
  • Ubah - data meta terakhir kali dari file diubah (mis. Izin)

Untuk menampilkan informasi ini, Anda dapat menggunakan statyang merupakan bagian dari coreutils.

stat akan menunjukkan kepada Anda juga beberapa informasi lebih lanjut seperti perangkat, inode, tautan, dll.

Ingat bahwa informasi semacam ini sangat tergantung pada filesystem dan opsi mount. Misalnya jika Anda memasang partisi dengan noatimeopsi, tidak ada informasi akses yang akan ditulis.

Utilitas untuk mengubah cap waktu adalah touch. Ada beberapa argumen untuk memutuskan stempel waktu yang akan diubah (mis. -A untuk waktu akses, -m untuk waktu modifikasi) dan untuk memengaruhi penguraian stempel waktu yang baru diberikan. Lihat man touchuntuk lebih jelasnya.

touchdapat menjadi berguna dalam kombinasi dengan cp -u( "salin hanya ketika file SOURCE lebih baru dari file tujuan atau ketika file tujuan hilang" ) atau untuk pembuatan file penanda kosong.


1
Terima kasih! Untuk perintah rsync, dalam "tidak peduli file mana yang lebih baru", dalam hal jenis cap waktu apa yang dimaksud dengan "baru". Juga, di samping catatan, apakah jenis file yang rsync pedulikan hanya berarti file biasa dan simlink, bukan tipe seperti pdf, jpg, htm, txt dll?
Tim

2
Secara umum, referensi ke waktu file adalah cap waktu "dimodifikasi". Misalnya, dari apa yang Anda lihat ls -l. Dan jenis file mengacu pada file vs symlink (atau jenis file lain seperti direktori atau perangkat). Bukan tipe data dalam file tersebut (teks vs. jpeg, dll).
Seth L

2
@Tim Dalam konteks itu adalah cap waktu yang dimodifikasi; rsync mengatakan bahwa ketika memutuskan apakah harus membuat cadangan file, itu tidak memeriksa untuk melihat apakah file sumber telah dimodifikasi lebih baru dari cadangan yang ada (yang umum dengan program cadangan); itu hanya memeriksa untuk melihat apakah file memiliki ukuran yang berbeda atau waktu modifikasi yang berbeda dan mendukung jika demikian
Michael Mrozek

1
Dan bagaimana saya tahu kapan file itu dibuat pertama kali? Apakah informasi ini dipertahankan di suatu tempat sama sekali atau hilang dalam pembaruan? jadi bisa dikatakan, berapa lama file tersebut telah ada ..?
xyz

1
The stat (2) halaman manual menjelaskan secara lebih rinci ketika orang-cap waktu berubah.
Cristian Ciupitu

35

Jawaban echox valid tetapi saya ingin menambahkan informasi mengenai waktu pembuatan file.

Dukungan Sistem File

Beberapa sistem file mendukung entri tambahan dalam inode mengenai waktu pembuatan (atau waktu lahir). Saya tahu bahwa ext4 mendukung fitur ini dan juga JFS dan BTRFS .

Namun sebagian besar alat dan API belum diperbarui untuk membaca informasi tambahan ini. Jadi meskipun itu bisa ada, itu tidak dapat diakses.

Misalnya pada Ubuntu 12.04 LTS saya mendapatkan yang berikut untuk file yang saya buat hari ini:

$ echo Just another test > /tmp/mytest
$ sleep 3
$ touch /tmp/mytest
$ sleep 2
$ cat /tmp/mytest > /dev/null
$ stat /tmp/mytest 
[...]
Access: 2012-06-05 13:33:44.279774711 +0200
Modify: 2012-06-05 13:33:34.611893317 +0200
Change: 2012-06-05 13:33:34.611893317 +0200
 Birth: -
$ sudo debugfs -R 'stat /tmp/mytest' /dev/sda1
[...]
 ctime: 0x4fcdee8e:91e30114 -- Tue Jun  5 13:33:34 2012
 atime: 0x4fcdee98:42b417dc -- Tue Jun  5 13:33:44 2012
 mtime: 0x4fcdee8e:91e30114 -- Tue Jun  5 13:33:34 2012
crtime: 0x4fcdee46:01258f1c -- Tue Jun  5 13:32:22 2012
[...]

Anda dapat melihat bahwa fungsi stat yang lebih baru memiliki bidang kelahiran, meskipun hasilnya tampaknya tidak benar. Dan melalui debugfs kita bisa mendapatkan informasi (crtime karena saya menggunakan sistem file ext4).

dukungan statx

Sekarang ada sejak Kernel 4.11 panggilan sistem statx baru , di atas dukungan yang lebih baik dari Y2038 atau sistem file jaringan, itu juga membawa beberapa fitur tambahan seperti akses btimewaktu kelahiran (waktu pembuatan). Dukungan untuk ext4 harus dalam rilis kernel yang sama 4.11.

Ada tambalan untuk menambahkan dukungan pada syscall baru ini di rilis Kernel berikutnya: misalnya BTRFS dan F2FS di Kernel 4.13, SMB3 di 4.14, GFS2 di 4.15, NFS di 4.16, dll.

Glibc yang akan datang akan menyediakan panggilan fungsi untuk menanyakan antarmuka ini (lihat berita Phoronix tentang dukungan statx glibc ). Jadi kami dapat mengharapkan dukungan untuk fitur ini di ruang pengguna segera.


Apakah Anda tahu jika btime tetap utuh ketika file dari Windows (Creation time) dipindahkan ke ext4 dan sebaliknya, seperti mtime?
Paradroid

@parroidroid maaf saya tidak tahu jawabannya. Jika Anda maksud di Linux ketika menyalin file dari NTFS ke ext4, orang akan perlu mencari di driver NTFS jika mendukung waktu pembuatan. Jika Anda maksud di bawah Windows, orang perlu melihat driver ext4 untuk Windows.
Huygens
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.