Як знайти дату створення файлу в Linux: повний технічний посібник

Linux не відкриває час створення файлу нативно через більшість стандартних інструментів простору користувача, але базові дані часто існують — складність полягає в тому, щоб знати точно, де шукати і яку файлову систему та версію ядра ви використовуєте. На файлових системах ext4, btrfs, xfs та tmpfs з ядром Linux 4.11+, справжні мітки часу створення (crtime) зберігаються в inode і можуть бути отримані за допомогою спеціальних низькорівневих утиліт. На старіших файлових системах або ядрах необхідно використовувати комбінацію метаданих inode, системних журналів та відладчиків, специфічних для файлової системи, щоб наблизитися до часу створення.

Цей посібник охоплює кожен надійний метод, доступний у 2024 році, включаючи технічні передумови, точний синтаксис команд, відомі режими відмов та коли кожен підхід є доречним для адміністрування виробничих систем.

Чому час створення файлу в Linux не є простим питанням

Кожен файл у Linux описується inode — структурою даних, що зберігає метадані, такі як дозволи, власність, розмір та мітки часу. Стандарт POSIX історично визначав три мітки часу:

• atime — час останнього доступу
• mtime — час останньої модифікації (вміст змінено)
• ctime — час зміни inode (метадані або вміст змінено)

Критично важливо: ctime — це не час створення. Це одна з найпоширеніших помилок серед адміністраторів, що мігрують із середовищ Windows. ctime оновлюється щоразу, коли змінюються дозволи, власність або файл перейменовується — це не має нічого спільного з тим, коли файл був вперше створений.

Справжній час створення, відомий як час народження або crtime, був доданий до структури inode ext4 і відкривається через системний виклик statx(), введений у ядрі Linux 4.11. Однак багато дистрибутивів постачали інструменти, які не відображали ці дані аж до відносно недавнього часу, саме тому плутанина зберігається.

Передумови щодо файлової системи та ядра

Перш ніж спробувати будь-який метод, перевірте своє середовище:

# 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

Якщо ви використовуєте середовище VPS Хостинг, базова файлова система майже завжди є ext4 або btrfs, що означає, що дані про час народження доступні — вам просто потрібні правильні інструменти для їх отримання.

Метод 1: Використання команди stat (рекомендована відправна точка)

Команда stat є правильним першим інструментом для спроби. На сучасних системах з ядром 4.11+ та підтримуваною файловою системою вона безпосередньо відобразить поле Birth.

stat /path/to/your/file

Приклад виводу на сучасній системі ext4:

  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

Якщо поле Birth показує - (тире) замість мітки часу, одне з наступного є правдою:

• Файлова система не зберігає час народження (ext2/ext3)
• Ядро старіше за 4.11
• Бінарний файл stat застарілий і не викликає statx()
• Файл був створений до оновлення файлової системи з ext3 до ext4

Програмне отримання лише мітки часу народження:

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)

Формат %W, що повертає 0, є надійною програмною перевіркою того, чи час народження справді недоступний.

Метод 2: Використання debugfs для файлових систем ext4

debugfs є остаточним низькорівневим інструментом для інспекції inode ext4. Він зчитує сиру структуру inode і може відкрити crtime навіть коли stat не спрацьовує через застарілий бінарний файл простору користувача.

Крок 1: Визначте номер inode вашого файлу

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

Крок 2: Визначте блоковий пристрій, що містить файлову систему

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

Крок 3: Запитайте debugfs з номером inode

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

Замініть 2883591 на ваш фактичний номер inode та /dev/vda1 на ваш фактичний пристрій. Вивід міститиме поле 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

Важлива операційна примітка: debugfs відкриває файлову систему в режимі лише для читання за замовчуванням при використанні -R, але все одно слід уникати запуску на активно використовуваній файловій системі без попереднього розмонтування або використання знімка. На виробничих Виділених серверах завжди надавайте перевагу запуску debugfs проти знімка файлової системи або зупиненого тому, щоб уникнути зчитування непослідовного стану inode.

Альтернативний синтаксис з використанням імені файлу безпосередньо:

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

Зверніть увагу, що шлях тут має бути відносним до кореня файлової системи, а не системного кореня. Якщо /dev/vda1 змонтовано в /, то /path/to/your/file працює як є.

Метод 3: Використання xfs_db для файлових систем XFS

На файлових системах XFS (поширених на системах RHEL/CentOS/Rocky Linux), еквівалентом debugfs є 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"

Шукайте поле v3.crtime у виводі. XFS v5 (за замовчуванням починаючи з RHEL 7) зберігає час народження нативно. XFS v4 — ні.

Метод 4: Використання інспекції підтому та файлів btrfs

На btrfs, stat з сучасним ядром є достатнім і повністю надійним. Однак для глибшої інспекції:

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

Для практичних цілей на btrfs, поле Birth у виводі stat є авторитетним.

Метод 5: Запит statx() безпосередньо через Python

Коли інструменти оболонки дають непослідовні результати, виклик системного виклику statx() безпосередньо з Python надає остаточну відповідь:

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")

Для більш точного наносекундного розрізнення використовуйте модуль ctypes для виклику statx() безпосередньо — це корисно у форензичних скриптах, де важлива точність мітки часу.

Метод 6: Пошук у системних журналах

Коли час народження на рівні файлової системи недоступний — наприклад, на файлових системах ext3 або файлах, що передують конвертації файлової системи — системні журнали стають резервним варіантом.

Пошук у журналі systemd:

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

Пошук у традиційному syslog:

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

Пошук у журналі аудиту (якщо налаштовано auditd):

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

Підсистема аудиту є найнадійнішим методом на основі журналів, оскільки вона записує системні виклики openat(), creat() та rename() з точними мітками часу. Однак її необхідно налаштувати заздалегідь — ви не можете ретроактивно аудитувати події створення файлів, що відбулися до увімкнення auditd.

Увімкнення аудиту створення файлів для каталогу:

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

Це відстежує /var/www/html на предмет подій запису, позначаючи їх ключем web_file_creation для зручного пошуку.

Метод 7: Використання ls — розуміння його обмежень

Команда ls часто згадується в посібниках як спосіб перевірки часу створення, але це вимагає суттєвого уточнення.

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

Критичне застереження: ls --time=birth працює лише на GNU coreutils 8.25+ і лише коли базова файлова система та ядро підтримують час народження. Якщо час народження недоступний, ls мовчки повертається до mtime без будь-якого попередження. Це мовчазне повернення є значною операційною небезпекою — ви можете вважати, що читаєте час створення, тоді як насправді читаєте час модифікації.

Завжди спочатку перевіряйте за допомогою stat. Використовуйте ls лише для відображення, а не для скриптової логіки.

# 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

Порівняння методів та матриця рішень

Реальні граничні випадки та підводні камені

Копіювання проти переміщення файлу: Коли файл копіюється (cp), призначення отримує новий inode з новим часом народження. Коли файл переміщується в межах тієї самої файлової системи (mv), inode зберігається і час народження не змінюється. Міжфайлосистемний mv поводиться як cp + rm, створюючи новий inode.

Конвертація файлової системи з ext3 до ext4: Файли, що існували до конвертації, матимуть crtime рівний нулю у своєму inode, оскільки ext3 ніколи не заповнював це поле. debugfs покаже crtime: 0x00000000:00000000. У цьому випадку mtime на момент конвертації є найкращим наближенням.

Docker та контейнерні середовища: Файлові системи контейнерів (overlay2, aufs) можуть неправильно передавати час народження. Файли всередині контейнерів можуть показувати час народження як час запуску контейнера, а не фактичний час створення файлу.

NFS монтування: Доступність часу народження повністю залежить від файлової системи NFS-сервера. Клієнт не має незалежних даних про час народження.

Відновлення з резервної копії: Файли, відновлені з архівів tar, зазвичай отримують новий inode і, таким чином, новий час народження, що відображає дату відновлення, а не оригінальну дату створення. Використовуйте tar --preserve-permissions та перевіряйте mtime для найближчого наближення до оригінального часу створення.

Для адміністраторів, що керують веб-додатками на VPS з cPanel, цілісність міток часу файлів є особливо важливою під час міграцій — завжди перевіряйте метадані inode після відновлення з резервної копії.

Увімкнення підтримки часу народження: налаштування файлової системи

Якщо ви налаштовуєте новий сервер і хочете гарантовану підтримку часу народження, переконайтеся в наступному:

Для ext4 — перевірте, що розмір inode становить 256 байт (необхідно для поля crtime):

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

Якщо розмір inode становить 128, час народження не може бути збережений. Це вимагає переформатування — не може бути змінено на існуючій файловій системі.

Створення нової файлової системи ext4 з 256-байтними inode (за замовчуванням починаючи з e2fsprogs 1.41):

sudo mkfs.ext4 -I 256 /dev/vdb1

Перевірка підтримки statx() ядром:

uname -r  # Must be >= 4.11

При розгортанні нової інфраструктури — чи то Спільний веб-хостинг чи виділені Виділені сервери — підтвердіть розмір inode файлової системи перед розгортанням додатків, що залежать від метаданих часу народження.

Практичний контрольний список для визначення часу створення файлу

Використовуйте це дерево рішень, коли вам потрібно знайти дату створення файлу:

• Спочатку перевірте версію ядра: uname -r — має бути 4.11+ для відображення Birth у stat
• Перевірте тип файлової системи: df -T /path/to/file — потрібна ext4, btrfs або xfs v5
• Запустіть stat для файлу: Якщо поле Birth показує мітку часу, у вас є відповідь
• Якщо Birth показує -: Запустіть debugfs (ext4) або xfs_db (xfs) з номером inode
• Якщо файлова система є ext3 або ext2: Поверніться до mtime як найкращого наближення
• Якщо вам потрібна точність рівня аудиту в майбутньому: Налаштуйте auditd зараз
• Якщо файл був нещодавно створений: Перевірте journalctl на підтверджуючі записи журналу
• У скриптах: Завжди перевіряйте stat --format="%W" на 0 перед тим, як довіряти значенню
• Після міграцій або відновлень: Вважайте час народження підозрілим; перехресно посилайтеся на mtime та маніфести резервних копій

Для середовищ, де цілісність файлів та точність міток часу є вимогами безпеки — наприклад, додатки, що обробляють SSL Сертифікати та файли криптографічних ключів — поєднання auditd з часом народження на рівні файлової системи дає вам двошаровий підхід до верифікації, який є обґрунтованим під час аудитів безпеки.

FAQ

Чи завжди Linux зберігає час створення файлу?

Ні. Лише файлові системи з 256-байтними inode (ext4, btrfs, xfs v5) зберігають час народження. ext2 та ext3 не мають поля часу народження у своїй структурі inode. Навіть на підтримуваних файлових системах файли, створені до оновлення файлової системи з ext3 до ext4, матимуть нульовий час народження.

У чому різниця між ctime та часом народження в Linux?

ctime — це час зміни inode — він оновлюється щоразу, коли змінюються метадані файлу (дозволи, власність, кількість посилань) або вміст. Це не час створення. Час народження (crtime) встановлюється один раз при першому створенні файлу і ніколи не змінюється. Багато адміністраторів плутають ці два поняття, що призводить до неправильних висновків аудиту.

Чи можна відновити час створення файлу після його втрати?

Якщо поле crtime inode дорівнює нулю або файлова система не підтримує його, оригінальний час створення не може бути відновлений лише з файлової системи. Ваші найкращі варіанти: перевірте журнали auditd, якщо вони були налаштовані, шукайте в журналах додатків або зверніться до маніфестів резервних копій, що записували метадані файлів під час резервного копіювання.

Чому ls --time=creation показує неправильний час?

ls мовчки повертається до mtime, коли час народження недоступний, без відображення будь-якого попередження. Це відома поведінкова проблема в GNU coreutils. Завжди використовуйте stat --format="%W" для програмної перевірки того, чи час народження справді доступний, перш ніж покладатися на вивід ls.

Яка команда дає найнадійніший час створення файлу на ext4?

debugfs -R 'stat <inode_number>' /dev/device є найнадійнішим методом на ext4, оскільки він зчитує сиру структуру inode безпосередньо, обходячи будь-які обмеження інструментів простору користувача. Для повсякденного використання на ядрі 4.11+, stat filename з полем Birth є еквівалентним і набагато зручнішим.