Использование даты / времени файла в качестве метаданных: надежно?

Большинство систем Unix не отслеживают время создания файлов. Они отслеживают время модификации файла, которое обновляется каждый раз при записи в файл. Если файлы записываются последовательно при их создании (т. Е. Первый файл полностью записывается до создания второго файла) и не изменяются позже, то порядок времени модификации будет таким же, как и порядок создания файлов, но в более сложных сценариях это может быть не то же самое.

Помимо времени модификации (mtime), в любых системах Unix есть еще две отметки времени файла: время доступа (atime) и время изменения inode (ctime). Время доступа обновляется при чтении файла, но некоторые системы (в частности, Linux по умолчанию) не всегда обновляют его из соображений производительности. Время изменения inode обновляется, когда некоторые метаданные об изменении файла (имя, разрешения и т. Д.; Также, когда файл записывается, но не когда он читается, даже если время изменяется). Ни atime, ни ctime вам не пригодятся.

Многие исторические системы Unix отслеживали временные метки файлов с разрешением в одну секунду. Современные системы Unix часто имеют лучшее разрешение, но для этого необходимо, чтобы на него обратили внимание несколько участников:

• Ядро, которое вы используете, должно поддерживать это более точное временное разрешение.
• Файловая система должна иметь возможность хранить это более точное временное разрешение.
• Любой компонент в цепочке (например, сервер NFS для файла в NFS) должен поддерживать это более точное временное разрешение.
• Любой инструмент, используемый для копирования файлов (архиватор, сетевой синхронизатор,…), должен иметь возможность сохранять более точное временное разрешение, а не только секунды.
• Приложение, считывающее время файла, должно учитывать субсекундное разрешение. Классические программные интерфейсы Unix не поддерживают субсекундное разрешение временных меток файлов, поэтому приложениям необходимо использовать относительно современный API (, стандартизированный в POSIX: 2008 - все еще относительно недавно, поскольку его внедрение было не очень быстрым).

Даже если все в цепочке поддерживают наносекундные временные метки, файлы будут иметь разные временные метки только в том случае, если они фактически созданы с интервалом более одного такта - то, что ядро ​​записывает наносекунды, не гарантирует, что оно заметит , что между созданием двух файлов прошло более одной наносекунды: считывание часов требует времени, поэтому это происходит не все время.Если у вас есть один поток, открывающий файл, записывающий данные и закрывающий файл перед переходом к следующему файлу, то я думаю, что на практике любая существующая системная система, которая записывает субсекундное разрешение, будет записывать разные временные метки, но вы берете небольшой риск. (Когда разные потоки записывают в файлы, даже с микросекундным разрешением, возможны коллизии временных меток - но обычно в этом случае вы не сможете полагаться на упорядочение чего-либо.)

Так что это возможно, и это надежно, поскольку пока компьютеры не работают намного быстрее, чем сейчас, при условии, что все используемые вами инструменты поддерживают разрешение менее секунды.Но вы находитесь во власти сбоя часов или инструмента, который вы не проверяли для поддержки субсекундных меток времени. Я рекомендую полагаться на имена файлов, там меньше всего может пойти не так.