В OS/X или FreeBSD это опция -U. Linux теперь также хранит время рождения/создания в большинстве своих собственных файловых систем, но API для его получения пока нет (2018 edit: начиная с ядра 4.11, появился системный вызов statx()
, а с glibc 2.28 - обертка libc для него, и с coreutils 8.31 GNU stat
может отображать его).
На файловых системах ext4 вы можете использовать debugfs, чтобы получить его, хотя:
$ sudo debugfs /dev/some/fs
stat /some/file
[...]
crtime: 0x53208d7a:9045625c -- Wed Mar 12 16:38:18 2014
[...]
(где /some/file
- путь внутри файловой системы)
Для файловых систем NTFS, и если вы используете ntfs-3g для монтирования, смотрите Как получить дату создания файла на логическом томе NTFS?
Если у вас достаточно свежая система Linux, вы можете использовать подкоманду xfs_io
statx
для вызова нового системного вызова statx()
и получить время рождения:
$ TZ=UTC0 xfs_io -c 'statx -v' /some/file
[...]
stat.btime = Thu Feb 7 17:11:20 2019
[...]
(здесь используется время UTC с TZ=UTC0
, так как иначе дата будет неоднозначной, поскольку смещение UTC не выводится). Или с помощью statx -r
, который дает вам наносекундную часть и более легко разбираемое время:
$ xfs_io -c 'statx -r' /some/file
[...]
stat.btime.tv_sec = 1549559480
stat.btime.tv_nsec = 964691587
[...]
См. также этот другой вопрос-ответ для способа вызвать statx()
, когда ваше ядро достаточно новое, чтобы поддерживать его, но когда ваша libc не поддерживает.
С GNU stat
8.31 или новее на системах с glibc 2.28 или новее и ядром 4.11 или новее:
$ stat /some/file | grep Birth:
Birth: 2018-05-24 16:27:28.415875403 +0100
$ stat -c '%.9W %w' /some/file
1527175648.415875403 2018-05-24 16:27:28.415875403 +0100
Традиционно в Unix не хранилось время создания.
Обратите внимание, что это значение может иметь меньшее значение, чем вы думаете.
Время модификации отражает возраст данных в этом файле, время доступа - когда к нему последний раз обращались, время изменения инода очень полезно, например, для программ резервного копирования, потому что вы знаете, что ничего в этом файле не изменилось с того времени (кроме, возможно, его полного пути, для которого вы можете посмотреть на ctime компонентов каталога).
Время создания - это время появления инода (ну, если счетчик ссылок идет от 0 до 1, этот инод мог быть выделен и удален в прошлой жизни), оно не отражает возраст данных, связанных с этим файлом (данные записываются после создания файла), он не говорит нам, существовал ли файл по этому пути в то время (файл, который мы рассматриваем, мог быть создан по другому пути и связан или перемещен туда позже).
В большинстве современных дистрибутивов Linux ядро распространяется в виде пакета, как и любое другое программное обеспечение/библиотека. Поэтому на примере Ansible у вас может быть такая задача, как:
- name: Ensure that latest kernel is installed
apt:
name: linux-image-amd64
state: latest
update_cache: yes
notify: reboot_server # You would need a corresponding handler that reboots the system
и это гарантирует, что при каждом запуске игры будет устанавливаться последний пакет ядра.
Однако ядро отличается от большинства других программных пакетов тем, что:
Существуют способы активации только что установленного ядра без перезагрузки, но они по-прежнему не являются общепринятым подходом.
Что касается того, следует ли вам обновлять ядро, в целом да.Учитывая длинный список громких сбоев в системе безопасности, вызванных устаревшим программным обеспечением (, и громкие сбои, которые, вероятно, являются лишь верхушкой айсберга ), все программное обеспечение следует поддерживать в актуальном состоянии. Недавние уязвимости Meltdown и Spectre подчеркивают, что ядро не является особенным и нуждается в обновлении, как и любой другой пакет.
Поддержание эффективной политики установки исправлений требует серьезного рассмотрения, учитывая компромисс между сбоями, которые могут возникнуть во время процесса, и сбоями, которые могут возникнуть, если это не будет сделано. Автоматизация, безусловно, может помочь, но каждая среда уникальна, поэтому вам нужно изучить свои собственные требования, чтобы оценить, насколько она уместна в вашем конкретном случае.
В любом случае, если вы скажете:
(a system where the distro itself - its kernel, shell(s) and internal utilities aren't changed at all)
Вы имеете в виду, что после установки вы никогда не будете повторно посещать и исправлять/обновлять/обновлять эти элементы, вы значительно увеличиваете риск взлома вашей системы.
Да, учитывая, что ядро ОС является программным, а не микропрограммным обеспечением (, как BIOS или загрузчик ), его можно изменить из оболочки, а также CM, который изменил бы его путем реализации оболочки в своем особым образом (подобно диалекту Ansible YAML ).