Cara Menemukan Tanggal Pembuatan File di Linux: Panduan Teknis Lengkap

Linux tidak secara native mengekspos waktu kelahiran file melalui sebagian besar alat userspace standar, tetapi data yang mendasarinya sering kali ada — tantangannya adalah mengetahui dengan tepat di mana harus mencari dan versi filesystem serta kernel apa yang Anda jalankan. Pada filesystem ext4, btrfs, xfs, dan tmpfs dengan Linux kernel 4.11+, timestamp kelahiran asli (crtime) disimpan dalam inode dan dapat diambil melalui utilitas tingkat rendah tertentu. Pada filesystem atau kernel yang lebih lama, Anda harus menggunakan kombinasi metadata inode, log sistem, dan debugger khusus filesystem untuk memperkirakan waktu pembuatan.

Panduan ini mencakup setiap metode yang dapat diandalkan yang tersedia pada tahun 2024, termasuk prasyarat teknis, sintaks perintah yang tepat, mode kegagalan yang diketahui, dan kapan setiap pendekatan sesuai untuk administrasi sistem produksi.

Mengapa Waktu Pembuatan File Linux Tidak Mudah

Setiap file di Linux dideskripsikan oleh sebuah inode — struktur data yang menyimpan metadata seperti izin, kepemilikan, ukuran, dan timestamp. Standar POSIX secara historis mendefinisikan tiga timestamp:

• atime — waktu akses terakhir
• mtime — waktu modifikasi terakhir (konten berubah)
• ctime — waktu perubahan inode (metadata atau konten berubah)

Yang penting, ctime bukan waktu pembuatan. Ini adalah salah satu kesalahpahaman paling umum di antara administrator yang bermigrasi dari lingkungan Windows. ctime diperbarui setiap kali izin berubah, kepemilikan berubah, atau file diganti namanya — ini tidak ada hubungannya dengan kapan file pertama kali dibuat.

Waktu pembuatan asli, yang dikenal sebagai birth time atau crtime, ditambahkan ke struktur inode ext4 dan diekspos melalui system call statx() yang diperkenalkan di Linux kernel 4.11. Namun, banyak distribusi yang menggunakan alat yang tidak menampilkan data ini hingga relatif baru-baru ini, itulah mengapa kebingungan ini masih berlanjut.

Prasyarat Filesystem dan Kernel

Sebelum mencoba metode apa pun, verifikasi lingkungan Anda:

# Check kernel version
uname -r

# Check filesystem type for a specific path
df -T /path/to/your/file

# Check filesystem mount options
findmnt -o TARGET,FSTYPE,OPTIONS /path/to/your/file

Jika Anda menjalankan lingkungan VPS Hosting, filesystem yang mendasarinya hampir selalu ext4 atau btrfs, artinya data birth time tersedia — Anda hanya perlu alat yang tepat untuk menampilkannya.

Metode 1: Menggunakan Perintah stat (Titik Awal yang Direkomendasikan)

Perintah stat adalah alat pertama yang tepat untuk dicoba. Pada sistem modern dengan kernel 4.11+ dan filesystem yang mendukung, perintah ini akan langsung menampilkan field Birth.

stat /path/to/your/file

Contoh output pada sistem ext4 modern:

  File: /home/deploy/app/config.yml
  Size: 4096            Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d    Inode: 2883591     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  deploy)   Gid: ( 1000/  deploy)
Access: 2024-03-15 09:22:14.812345678 +0000
Modify: 2024-03-10 14:05:33.123456789 +0000
Change: 2024-03-10 14:05:33.123456789 +0000
 Birth: 2024-03-08 11:47:02.987654321 +0000

Jika field Birth menampilkan - (tanda hubung) alih-alih timestamp, salah satu dari berikut ini berlaku:

• Filesystem tidak menyimpan birth time (ext2/ext3)
• Kernel lebih lama dari 4.11
• Binary stat sudah usang dan tidak memanggil statx()
• File dibuat sebelum filesystem diupgrade dari ext3 ke ext4

Mengekstrak hanya timestamp birth secara terprogram:

stat --format="%w" /path/to/your/file
# Returns '-' if unavailable, or ISO 8601 timestamp if available

stat --format="%W" /path/to/your/file
# Returns Unix epoch integer (0 if unavailable)

Format %W yang mengembalikan 0 adalah pemeriksaan terprogram yang dapat diandalkan untuk mengetahui apakah birth time benar-benar tidak tersedia.

Metode 2: Menggunakan debugfs untuk Filesystem ext4

debugfs adalah alat tingkat rendah definitif untuk inspeksi inode ext4. Alat ini membaca struktur inode mentah dan dapat mengekspos crtime bahkan ketika stat gagal karena binary userspace yang lebih lama.

Langkah 1: Identifikasi nomor inode file Anda

ls -i /path/to/your/file
# Output example: 2883591 /path/to/your/file

Langkah 2: Identifikasi perangkat blok yang menghosting filesystem

df /path/to/your/file
# Output shows the device, e.g., /dev/sda1 or /dev/vda1

Langkah 3: Query debugfs dengan nomor inode

sudo debugfs -R 'stat <2883591>' /dev/vda1

Ganti 2883591 dengan nomor inode Anda yang sebenarnya dan /dev/vda1 dengan perangkat Anda yang sebenarnya. Output akan menyertakan field crtime:

Inode: 2883591   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 3421897654    Version: 0x00000000:00000001
User:  1000   Group:  1000   Project:     0   Size: 4096
File ACL: 0
Links: 1   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x65ee1f4d:1d4c5800 -- Sun Mar 10 14:05:33 2024
 atime: 0x65f4a1ae:c6b5c000 -- Fri Mar 15 09:22:14 2024
 mtime: 0x65ee1f4d:1d4c5800 -- Sun Mar 10 14:05:33 2024
crtime: 0x65e4b2c6:eb851400 -- Thu Mar 08 11:47:02 2024
Size of extra inode fields: 28

Catatan operasional penting: debugfs membuka filesystem dalam mode read-only secara default saat menggunakan -R, tetapi Anda tetap harus menghindari menjalankannya pada filesystem yang sangat aktif tanpa terlebih dahulu melakukan unmount atau menggunakan snapshot. Pada Dedicated Servers produksi, selalu lebih baik menjalankan debugfs terhadap snapshot filesystem atau volume yang telah dihentikan sementara untuk menghindari pembacaan status inode yang tidak konsisten.

Sintaks alternatif menggunakan nama file secara langsung:

sudo debugfs -R "stat /path/to/your/file" /dev/vda1

Perhatikan bahwa path di sini harus relatif terhadap root filesystem, bukan root sistem. Jika /dev/vda1 di-mount di /, maka /path/to/your/file berfungsi apa adanya.

Metode 3: Menggunakan xfs_db untuk Filesystem XFS

Pada filesystem XFS (umum pada sistem RHEL/CentOS/Rocky Linux), padanan dari debugfs adalah xfs_db.

# Get inode number first
ls -i /path/to/your/file

# Unmount or use read-only mode
sudo xfs_db -r /dev/sda1 -c "inode <inode_number>" -c "print"

Cari field v3.crtime dalam output. XFS v5 (default sejak RHEL 7) menyimpan birth time secara native. XFS v4 tidak.

Metode 4: Menggunakan Inspeksi Subvolume dan File btrfs

Pada btrfs, stat dengan kernel modern sudah cukup dan sepenuhnya dapat diandalkan. Namun, untuk inspeksi lebih mendalam:

sudo btrfs inspect-internal dump-tree /dev/sdb | grep -A 20 "inode ref"

Untuk keperluan praktis pada btrfs, field Birth dalam output stat bersifat otoritatif.

Metode 5: Melakukan Query statx() Secara Langsung melalui Python

Ketika alat shell memberikan hasil yang tidak konsisten, memanggil syscall statx() langsung dari Python memberikan jawaban yang definitif:

import os
import stat

result = os.stat("/path/to/your/file")
# st_birthtime is available on systems where statx() returns it
if hasattr(result, 'st_birthtime'):
    import datetime
    birth = datetime.datetime.fromtimestamp(result.st_birthtime)
    print(f"Birth time: {birth}")
else:
    print("Birth time not available on this platform/filesystem")

Untuk resolusi nanodetik yang lebih presisi, gunakan modul ctypes untuk memanggil statx() secara langsung — ini berguna dalam skrip forensik di mana presisi timestamp sangat penting.

Metode 6: Mencari di Log Sistem

Ketika birth time di tingkat filesystem tidak tersedia — misalnya, pada filesystem ext3 atau file yang mendahului konversi filesystem — log sistem menjadi fallback.

Cari di jurnal systemd:

journalctl --since="2024-01-01" | grep "your_filename"

Cari di syslog tradisional:

grep "your_filename" /var/log/syslog
grep "your_filename" /var/log/messages

Cari di log audit (jika auditd dikonfigurasi):

sudo ausearch -f /path/to/your/file

Subsistem audit adalah metode berbasis log yang paling dapat diandalkan karena merekam syscall openat(), creat(), dan rename() dengan timestamp yang presisi. Namun, subsistem ini harus dikonfigurasi terlebih dahulu — Anda tidak dapat mengaudit secara retroaktif peristiwa pembuatan file yang terjadi sebelum auditd diaktifkan.

Aktifkan auditing pembuatan file untuk sebuah direktori:

sudo auditctl -w /var/www/html -p w -k web_file_creation

Ini memantau /var/www/html untuk peristiwa penulisan, menandainya dengan kunci web_file_creation untuk kemudahan pengambilan.

Metode 7: Menggunakan ls — Memahami Keterbatasannya

Perintah ls sering dikutip dalam panduan sebagai cara untuk memeriksa waktu pembuatan, tetapi ini memerlukan kualifikasi yang signifikan.

ls -l --time=birth /path/to/your/file
ls -l --time=creation /path/to/your/file  # synonym on some systems

Peringatan penting: ls --time=birth hanya berfungsi pada GNU coreutils 8.25+ dan hanya ketika filesystem dan kernel yang mendasarinya mendukung birth time. Jika birth time tidak tersedia, ls secara diam-diam kembali ke mtime tanpa peringatan apa pun. Fallback diam ini merupakan bahaya operasional yang signifikan — Anda mungkin mengira sedang membaca waktu pembuatan padahal sebenarnya membaca waktu modifikasi.

Selalu verifikasi dengan stat terlebih dahulu. Gunakan ls hanya untuk keperluan tampilan, bukan untuk logika skrip.

# Safer: check stat output explicitly before relying on ls
BIRTH=$(stat --format="%W" /path/to/your/file)
if [ "$BIRTH" -eq 0 ]; then
    echo "Birth time unavailable, falling back to mtime"
    stat --format="%y" /path/to/your/file
else
    echo "Birth time: $(date -d @$BIRTH)"
fi

Perbandingan Metode dan Matriks Keputusan

Kasus Edge dan Jebakan di Dunia Nyata

File disalin vs. dipindahkan: Ketika file disalin (cp), tujuan mendapatkan inode baru dengan birth time baru. Ketika file dipindahkan dalam filesystem yang sama (mv), inode dipertahankan dan birth time tidak berubah. mv lintas filesystem berperilaku seperti cp + rm, membuat inode baru.

Konversi filesystem dari ext3 ke ext4: File yang ada sebelum konversi akan memiliki crtime bernilai nol dalam inode mereka, karena ext3 tidak pernah mengisi field tersebut. debugfs akan menampilkan crtime: 0x00000000:00000000. Dalam kasus ini, mtime pada saat konversi adalah perkiraan terbaik.

Docker dan lingkungan container: Filesystem container (overlay2, aufs) mungkin tidak meneruskan birth time dengan benar. File di dalam container mungkin menampilkan birth time sebagai waktu mulai container daripada waktu pembuatan file yang sebenarnya.

Mount NFS: Ketersediaan birth time sepenuhnya bergantung pada filesystem server NFS. Klien tidak memiliki data birth time yang independen.

Pemulihan backup: File yang dipulihkan dari arsip tar biasanya mendapatkan inode baru dan dengan demikian birth time baru yang mencerminkan tanggal pemulihan, bukan tanggal pembuatan asli. Gunakan tar --preserve-permissions dan periksa mtime untuk perkiraan terdekat dari waktu pembuatan asli.

Bagi administrator yang mengelola aplikasi web pada VPS dengan cPanel, integritas timestamp file sangat penting selama migrasi — selalu verifikasi metadata inode setelah memulihkan dari backup.

Mengaktifkan Dukungan Birth Time: Penyetelan Filesystem

Jika Anda menyiapkan server baru dan menginginkan dukungan birth time yang terjamin, pastikan hal-hal berikut:

Untuk ext4 — verifikasi ukuran inode adalah 256 byte (diperlukan untuk field crtime):

sudo tune2fs -l /dev/vda1 | grep "Inode size"
# Should return: Inode size: 256

Jika ukuran inode adalah 128, birth time tidak dapat disimpan. Ini memerlukan pemformatan ulang — tidak dapat diubah pada filesystem yang sudah ada.

Buat filesystem ext4 baru dengan inode 256-byte (default sejak e2fsprogs 1.41):

sudo mkfs.ext4 -I 256 /dev/vdb1

Verifikasi kernel mendukung statx():

uname -r  # Must be >= 4.11

Saat menyediakan infrastruktur baru — baik Shared Web Hosting maupun Dedicated Servers bare-metal — konfirmasikan ukuran inode filesystem sebelum men-deploy aplikasi yang bergantung pada metadata birth time.

Daftar Periksa Praktis untuk Menentukan Waktu Pembuatan File

Gunakan pohon keputusan ini ketika Anda perlu menemukan tanggal pembuatan file:

• Periksa versi kernel terlebih dahulu: uname -r — harus 4.11+ agar stat menampilkan Birth
• Periksa tipe filesystem: df -T /path/to/file — diperlukan ext4, btrfs, atau xfs v5
• Jalankan stat pada file: Jika field Birth menampilkan timestamp, Anda sudah mendapat jawabannya
• Jika Birth menampilkan -: Jalankan debugfs (ext4) atau xfs_db (xfs) dengan nomor inode
• Jika filesystem adalah ext3 atau ext2: Kembali ke mtime sebagai perkiraan terbaik
• Jika Anda memerlukan akurasi tingkat audit ke depannya: Konfigurasikan auditd sekarang
• Jika file baru saja dibuat: Periksa journalctl untuk entri log yang mendukung
• Dalam skrip: Selalu periksa stat --format="%W" untuk 0 sebelum mempercayai nilainya
• Setelah migrasi atau pemulihan: Anggap birth time sebagai tidak dapat dipercaya; silang referensi dengan mtime dan manifes backup

Untuk lingkungan di mana integritas file dan akurasi timestamp merupakan persyaratan keamanan — seperti aplikasi yang menangani SSL Certificates dan file kunci kriptografi — menggabungkan auditd dengan birth time di tingkat filesystem memberi Anda pendekatan verifikasi dua lapis yang dapat dipertahankan dalam audit keamanan.

FAQ

Apakah Linux selalu menyimpan waktu pembuatan file?

Tidak. Hanya filesystem dengan inode 256-byte (ext4, btrfs, xfs v5) yang menyimpan birth time. ext2 dan ext3 tidak memiliki field birth time dalam struktur inode mereka. Bahkan pada filesystem yang mendukung, file yang dibuat sebelum upgrade filesystem dari ext3 ke ext4 akan memiliki birth time nol.

Apa perbedaan antara ctime dan birth time di Linux?

ctime adalah waktu perubahan inode — diperbarui setiap kali metadata file (izin, kepemilikan, jumlah link) atau konten berubah. Ini bukan waktu pembuatan. Birth time (crtime) ditetapkan sekali saat file pertama kali dibuat dan tidak pernah berubah. Banyak administrator yang mengacaukan keduanya, yang menyebabkan kesimpulan audit yang salah.

Bisakah saya memulihkan waktu pembuatan file setelah hilang?

Jika field crtime inode bernilai nol atau filesystem tidak mendukungnya, waktu pembuatan asli tidak dapat dipulihkan dari filesystem saja. Pilihan terbaik Anda adalah: periksa log auditd jika sudah dikonfigurasi, cari di log aplikasi, atau konsultasikan manifes backup yang merekam metadata file pada saat backup.

Mengapa ls --time=creation menampilkan waktu yang salah?

ls secara diam-diam kembali ke mtime ketika birth time tidak tersedia, tanpa menampilkan peringatan apa pun. Ini adalah masalah perilaku yang diketahui dalam GNU coreutils. Selalu gunakan stat --format="%W" untuk memverifikasi secara terprogram apakah birth time benar-benar tersedia sebelum mengandalkan output ls.

Perintah mana yang memberikan waktu pembuatan file paling dapat diandalkan pada ext4?

debugfs -R 'stat <inode_number>' /dev/device adalah metode paling dapat diandalkan pada ext4 karena membaca struktur inode mentah secara langsung, melewati keterbatasan alat userspace apa pun. Untuk penggunaan sehari-hari pada kernel 4.11+, stat filename dengan field Birth setara dan jauh lebih praktis.