Все еще нет интерфейса ядра Linux для получения даты создания файла?

В течение долгого времени Linux не беспокоился о датах создания файлов, потому что ни одна из файловых систем, которые он обычно использовал, не поддерживала их. Однако в настоящее время 2 широко используемые файловые системы (NTFS и ext4) записывают даты создания файлов.

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

Когда я выяснил, почему это так, я увидел, что кто-то еще недавно подал на него отчет об ошибке, и ответ связывается с основной проблемой, которая просто гласит: «В настоящее время нет интерфейса ядра Linux для получения этой информации [файл» Дата создания]". Мне кажется замечательным, что это, по-видимому, все еще так, поскольку люди просили, чтобы statэта информация отображалась годами (и statвыводит ли Birthполе, даже если оно, очевидно, еще не поддерживает его! Они добавили его в ожидании?)

Так правда ли, что в настоящее время нет интерфейса ядра Linux для получения даты создания файла? Есть ли план реализовать это когда-либо?

РЕДАКТИРОВАТЬ: Хорошая новость, 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, вы можете жестко закодировать его. На архитектурах amd64 это 332. Или попробуйте:

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

Сейчас это время рождения редко бывает полезным. Это не возраст данных в файле (данные записываются в файлы после того, как они были созданы), а также не обязательно время, когда файл появился под этим именем в каталоге (он мог быть создан под другим именем и переименован или связан там и содержание или атрибуты были изменены несколько раз между).