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

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

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

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

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

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

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

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

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

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

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

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

Ответ 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 ). Таким образом, мы можем ожидать поддержку этой функции в пользовательском пространстве довольно скоро.