it-swarm-ru.tech

метка времени, время модификации и время создания файла

Я просто знаю, что ls -t а также ls -f дают различную сортировку файлов и подкаталогов в каталоге.

  • В чем разница между меткой времени, временем модификации и временем создания файла?
  • Как получить и изменить эти виды информации с помощью команд?
  • С точки зрения какой информации люди говорят, что файл "новее", чем другой?
  • Какие виды изменения информации не сделают файл другим?

Например, я видел, кто-то написал:

По умолчанию программа rsync только проверяет, отличаются ли файлы по размеру и времени. Не важно, какой файл более новый, если он другой, он перезаписывается. Вы можете передать флаг --update в rsync, что заставит его пропускать файлы в месте назначения, если они новее, чем файл в источнике, но только в том случае, если они относятся к одному и тому же типу файла. Это означает, что, например, если исходный файл является обычным файлом, а пункт назначения является символической ссылкой, файл назначения будет перезаписан независимо от метки времени.

Напомним, что тип файла здесь означает только обычный файл и симлинк, а не такой тип, как pdf, jpg, htm, txt и т.д.?

108
Tim

Существует 3 вида "временных меток":

  • Доступ - последний раз, когда файл был прочитан
  • Изменить - последний раз, когда файл был изменен (содержимое было изменено)
  • Изменить - в последний раз метаданные файла были изменены (например, разрешения)

Чтобы вывести эту информацию, вы можете использовать stat , которая является частью coreutils.

stat покажет вам еще некоторую информацию, такую ​​как устройство, inode, ссылки и т. д.

Помните, что такого рода информация сильно зависит от файловой системы и параметров монтирования. Например, если вы смонтируете раздел с параметром noatime, информация о доступе не будет записана.

Утилита для изменения временных меток будет touch. Существуют некоторые аргументы, чтобы решить, какую временную метку изменить (например, -a для времени доступа, -m для времени модификации) и повлиять на синтаксический анализ новой данной временной метки. Видеть man touch для более подробной информации.

touch может пригодиться в сочетании с cp -u ( "копировать только в том случае, если файл SOURCE новее, чем файл назначения, или когда файл назначения отсутствует" ) или для создания пустого маркера файлы.

146
echox

Ответ echox действителен, но я хочу добавить информацию о времени создания файла.

Поддержка файловой системы

Некоторые файловые системы поддерживают дополнительную запись в inode относительно времени создания (или времени рождения). Я знаю, что ext4 поддерживает эту функцию , а также JFS и BTRFS .

Однако большинство инструментов и API еще не были обновлены, чтобы прочитать эту дополнительную информацию. Так что, хотя оно может быть там, оно недоступно.

Например, в Ubuntu 12.04 LTS для файла, который я создал сегодня, я получаю следующее:

$ echo Just another test > /tmp/mytest
$ sleep 3
$ touch /tmp/mytest
$ sleep 2
$ cat /tmp/mytest > /dev/null
$ stat /tmp/mytest 
[...]
Access: 2012-06-05 13:33:44.279774711 +0200
Modify: 2012-06-05 13:33:34.611893317 +0200
Change: 2012-06-05 13:33:34.611893317 +0200
 Birth: -
$ Sudo debugfs -R 'stat /tmp/mytest' /dev/sda1
[...]
 ctime: 0x4fcdee8e:91e30114 -- Tue Jun  5 13:33:34 2012
 atime: 0x4fcdee98:42b417dc -- Tue Jun  5 13:33:44 2012
 mtime: 0x4fcdee8e:91e30114 -- Tue Jun  5 13:33:34 2012
crtime: 0x4fcdee46:01258f1c -- Tue Jun  5 13:32:22 2012
[...]

Вы можете видеть, что более новая функция stat имеет поле рождения, хотя вывод кажется неправильным. И через debugfs мы можем получить информацию (crtime, как я на файловой системе ext4).

поддержка statx

Теперь есть поскольку Kernel 4.11 - новый системный вызов statx , в дополнение к лучшей поддержке Y2038 или сетевых файловых систем, он также предоставляет несколько дополнительных функций, таких как btime или время рождения ( время создания) доступ. Поддержка ext4 должна быть в том же выпуске ядра 4.11.

Были исправления для добавления поддержки этого нового системного вызова в более поздних выпусках ядра: например, BTRFS и F2FS в ядре 4.13, SMB3 в 4.14, GFS2 в 4.15, NFS в 4.16 и т.д.

Предстоящий glibc предоставит вызов функции для запроса этого интерфейса (см. Новости Phoronix о поддержке statx glibc ). Таким образом, мы можем ожидать поддержку этой функции в пользовательском пространстве довольно скоро.

38
Huygens