Определите эффективную точность метки времени, возвращаемую "stat ()"

Question

Я пытаюсь определить эффективную точность поля st_mtim.tv_nsec struct stat в программном обеспечении для конкретной директории / файловой системы.

Есть ли способ сделать это, который определяетТочность изменения времени файловой системы (а не точность «наносекунды» библиотеки или точность кэша каталогов ОС)?

ДОБАВЛЕНО: Для некоторой справочной информации это инструмент, который обновляет некоторые файлы.Основной сценарий: « Если файл в первой группе файлов может быть новее, чем любой файл во второй группе файлов, то используйте первую группу файлов для обновления второй группы файлов », а затемby " Если файл во второй группе файлов может быть новее, чем любой файл в третьей группе файлов, то использовать вторую группу файлов для обновления третьей группы файлов ".

Проблема у меня заключается в том, что при первом запуске инструмента (после изменения файла в первой группе) он обновит вторую группу файлов, а затем обновит третью группу файлов (что является правильным поведением).);но во время второго запуска инструмента (когда ничего не изменилось) вторая группа файлов и третья группа файлов будут иметь одинаковые временные метки, поэтому он должен предполагать, что файл в третьей группе может быть новее, и он будет обновлятьсятретья группа файлов без причины.

Чтобы исправить первоначальную проблему, я ввел задержку ("nanosleep ();") перед обновлением третьей группы файлов;так что при следующем запуске инструмента третья группа файлов будет немного старше.Это позволяет избежать ненужных обновлений.

Конечно, все не так просто - существует произвольное количество «групп файлов», которые взаимозависимы (не только 3 группы).

Это приноситменя к моей текущей проблеме - для некоторых файловых систем точность отметки времени составляет всего 2 секунды, а необходимая задержка "наихудшего случая" огромна (например, она составляет не менее 60 секунд задержек для 31 уровня "групп").файлы ").Для большинства файловых систем метки времени гораздо более точны, и большое количество потерянного времени может исчезнуть.Конечно, инструмент должен быть «максимально переносимым», и я не могу сделать никаких предположений о точности отметки времени (было бы очень легко, если бы я знал, что файловая система всегда будет ext4 или что-то в этом роде).

Answer 1

Согласно этому OpenGroup Link ,

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

Таким образом, вам гарантируется, что она будет составлять не менее одной секунды.

Также, согласно этой справочной странице Linux по stat (2) :

Начиная с ядра 2.5.48, структура stat поддерживает разрешение наносекунд для трех файловых отметок времени.

Answer 2

Linux или Windows не являются ОСРВ (операционными системами реального времени), и информация такого типа может быть не более 100 мс, обычно + -10 мс, насколько я помню, это был стандартный временной интервал планировщика.

Я не в курсе этой информации, но я почти уверен, что так оно и есть.

РЕДАКТИРОВАТЬ

Текущая реализация nanosleep () основана на нормальном механизм таймера ядра, который имеет разрешение 1 / Гц с (см. время (7)). Поэтому nanosleep () всегда делает паузу как минимум для указанное время, однако это может занять до 10 мс дольше указанного пока процесс не станет снова работоспособным. По той же причине значение, возвращаемое в случае доставленного сигнала в * rem, обычно округляется до следующего большего кратного 1 / Гц с.

С здесь

Answer 3

Насколько я знаю, это невозможно сделать.

Единственный практический обходной путь - позволить конечному пользователю настроить его так, как ему удобно.

Примечание: я сам пытался найти способ и спросил здесь и несколько других мест (в основном IRC-каналы для C и POSIX); и никто (включая меня) не смог найти способ сделать это.