метка времени, время изменения и созданное время файла
С точки зрения системного администратора я нашел несколько незначительных различий, главным образом в dpkg/rpm комплекте инструментальных средств, а не формате пакета.
dpkg-divertпозволяет иметь Ваш собственный файл, перемещают тот, прибывающий из пакета. Это может быть спаситель, когда у Вас есть программа, которая ищет файл в/usrили/libи не возьмет/usr/localдля ответа. Идея была предложена, но насколько я могу сказать не принятый в об/мин.Когда я в последний раз администрировал основанные на об/мин системы (который по общему признанию был несколько лет назад, возможно, ситуация улучшилась), об/мин всегда перезаписывал бы измененные конфигурационные файлы и перемещал бы мои настройки в
*.rpmsave(IIRC). Это сделало мою систему незагрузочной, по крайней мере, однажды. Dpkg спрашивает меня, что сделать с хранением моих настроек как значение по умолчанию.Двоичный пакет об/мин может объявить зависимости от файлов, а не пакетов, который допускает более прекрасное управление, чем deb пакет.
Вы не можете установить RPM-пакет версии N в системе с версией n-1 инструментов об/мин. Это могло бы относиться к dpkg также, кроме формата не изменяется как часто.
dpkg база данных состоит из текстовых файлов. База данных об/мин является двоичной. Это делает dpkg базу данных легкой исследовать и восстановить. С другой стороны, пока ничто не идет не так, как надо, об/мин может быть намного быстрее (установка deb требует чтения тысячи маленьких файлов).
deb пакет использует стандартные форматы (
ar,tar,gzip) таким образом, можно осмотреть, и в тонкой настройке повышения), deb пакеты легко. RPM-пакеты не почти как дружественные.
Существует 3 вида "меток времени":
- Доступ - прошлый раз файл был считан
- Измените - в прошлый раз, когда файл был изменен (содержание было изменено),
- Изменение - прошлый раз метаданные файла был изменен (например, полномочия)
Для отображения этой информации можно использовать stat который является частью coreutils.
stat покажет Вам также еще некоторую информацию как устройство, inodes, ссылки, и т.д.
Помните, что этот вид информации зависит высоко от файловой системы, и смонтируйте опции. Например, если Вы монтируете раздел с noatime опция, никакая информация о доступе не будет записана.
Утилита для изменения меток времени была бы touch. Существуют некоторые аргументы для решения который метка времени измениться (например,-a в течение времени доступа,-m в течение времени изменения) и влиять на парсинг новой данной метки времени. Посмотрите man touch для получения дополнительной информации.
touch может стать удобным в сочетании с cp -u ("копируют только, когда ИСХОДНЫЙ ФАЙЛ является более новым, чем целевой файл или когда целевой файл отсутствует"), или для создания пустых файлов маркера.
Ответ 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
[...]
Вы видите, что более новая функция статистики имеет поле рождения, хотя вывод кажется неправильным. И через debugfs мы можем получить информацию (crtime, как я нахожусь в ext4 файловой системе).
поддержка statx
Существует теперь начиная с Ядра 4.11 новый statx системный вызов, сверх лучшей поддержки Y2038 или сетевых файловых систем, это также приносит несколько дополнительных функций как btime или время рождения (время создания) доступ. Поддержка ext4 должна быть в том же выпуске 4.11 ядра.
Были патчи для добавления поддержки этому новому syscall в более поздних выпусках Ядра: например, BTRFS и F2FS в Ядре 4.13, SMB3 в 4,14, GFS2 в 4,15, NFS в 4,16, и т.д.
Прибытие glibc обеспечит вызов функции запросить этот интерфейс (см. новости Phoronix о glibc statx поддержка). Таким образом, мы можем ожидать поддержку этой функции в пространстве пользователя довольно скоро.
ls -l. И тип файла относится к файлу по сравнению с символьной ссылкой (или другие типы файлов как каталоги или устройства). Не, что тип данных в файле (текст по сравнению с jpeg, и т.д.). – Seth L 27.09.2010, 21:12