Чи все ще немає інтерфейсу ядра Linux для отримання дати створення файлу?

Давно Linux не переймався датами створення файлів, оскільки жодна з файлових систем, які він зазвичай використовував, не підтримувала їх. Однак зараз у двох файлових системах (NTFS та ext4) обидва дати створення файлів запису.

Однак statкоманда все ще виводить Birth: -файлову систему ext4, хоча ми можемо бачити, що ext4 зберігає дату створення файлу за допомогою debugfs -R 'stat <inode_number>' /dev/file_device.

Коли я роздивився, чому це так, я побачив, що хтось ще недавно подав звіт про помилку, і відповідь посилається на випускну проблему, яка просто стверджує, що "в даний час немає інтерфейсу ядра Linux, щоб отримати цю інформацію [файл дата створення]". Мені здається чудовим, що це, мабуть, все-таки так, оскільки люди просили statвідображати цю інформацію роками (і statвидають Birthполе, хоча воно, мабуть, ще не підтримує! Чи додали його в очікуванні?)

Тож чи все ж правда, що на даний момент не існує інтерфейсу ядра Linux для отримання дати створення файлу? Чи існує план коли-небудь здійснити це?

EDIT: Добрі новини statx()були об'єднані, тому вони повинні бути доступні у випуску 4.11.

• https://lwn.net/Articles/716302/
• https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a528d35e8bfcc521d7cb70aaf03e1bd296c8493f

Робота xstat (), в даний час statx (), була переглянута в 2016 році.

• http://lwn.net/Articles/685791/
• http://lwn.net/Articles/686106/

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

оскільки жодна з файлових систем, яку він зазвичай використовував, не підтримувала їх

З того, що я можу сказати (вибачте за кучу посилань, пам’яті та googlage, нічого згуртованого, щоб перелічити тут як посилання), це було ніколи тому, що підкреслювані системи не підтримували атрибути часу створення, а тому що жодна з них не могла навіть погоджуйтеся, що це була корисна особливість.

Див. Http://www.pathname.com/fhs/pub/fhs-2.3.html

POSIX викладає три позначки часу. Жоден з них не є часом створення.

Якщо я добре пам’ятаю, аргумент вийшов приблизно так:

> Give me a use case where we can't already do that using what we already have.
< Some examples were submitted
> All of these are convoluted beyond usefulness. 
> Ok, Ok, *maybe* a couple of these don't suck. 
> Now how do you see handling file systems that don't track this?
< several ideas that were not the same. 
< Basically everyone had a special case that would work, but not 
< one that always works. Fight about fallbacks and other special handling. 
> Ok, lets table that for now. What should we call this field
< At least 6 different answers emerged.
> So, you want to break POSIX standards, 
> you can't really come up with a good reason why, 
> you can't come up with a good fall back, and 
> you can't even come up with a name. 
> Sounds like it's specific to the file system to me, and that 
> should be "extended data" accessible by tools and not as 
> a core stat in the Kernel.

Зараз багато цього - це пам'ять та читання старих списків розсилки. Я теж не стояв в центрі аргументів. Я був у списку розсилки через те, що я працював у жировому драйвері для вбудованої системи Linux. Я зазначу це, оскільки, безумовно, є більш авторитетні джерела, то моя пам’ять про щось, про що я лише хвилювався.

Я пам’ятаю, що велика справа була поєднанням того факту, що ніхто не міг придумати гарного випадку використання, і ніхто не міг домовитися про те, як обробити поле для інших 40 часто використовуваних файлових систем, які не підтримують час створення, і навіть придумати назву для поля перетворилося на масштабну дискусію.

Час народження є в декількох рідних файлових системах Linux, а не тільки у ext4.

Починаючи з версії 4.11 ядра Linux (квітень 2017 року), є новий statx()системний виклик для його отримання. Тим НЕ менше, відповідна функція обгортка була додана в GNU Libc поки (станом на 2018-06-26. 2019 редагувати додали в 2.28), а також інструменти , такі як GNU stat, ls, findне було оновлено , щоб використовувати його ( 2019-08- 22 редагування GNU statв системах GNU / Linux з glibc 2.28 або вище підтримує його, оскільки coreutils 8.31)

Ви можете це зробити, perlхоча з чимось на зразок:

perl -MPOSIX -e '
  require "syscall.ph";
  $buf = "\0" x 0x100; # enough space for a struct statx
  for (@ARGV) {
    # hardcode: AT_FDCWD == -100
    #           AT_SYMLINK_NOFOLLOW = 0x100 (lstat()-like)
    #           STATX_BTIME = 0x800 for the mask
    #           80: offset of the btime in the struct
    syscall(&SYS_statx, -100, $_, 0x100, 0x800, $buf) == 0
      or die "$_: $!\n";
    ($t, $n) = unpack("x80QQ", $buf);
    $n = sprintf("%09d", $n);
    print strftime("%F %T.$n %z\n", localtime $t)
  }' -- "$file"

Якщо у вас syscall.phнемає SYS_statx, ви також можете його жорстко закодувати. Це 332 архітектури amd64. Або спробуйте:

printf '#include <syscall.h>\n__NR_statx\n' | gcc -E -xc - | tail -n 1

Тепер, коли час народження рідко корисний. Це не вік даних у файлі (дані записуються у файли після їх створення), а також не обов'язково час, коли файл з'явився під цим іменем у каталозі (він міг бути створений як інше ім’я та перейменований чи зв'язаний там і зміст або атрибути були змінені між собою кілька разів).