В настоящее время я проверяю контрольную сумму XOR с измененным временем файла (st_mtime из fstat) для каждого файла в дереве. Я связываю это с количеством найденных файлов и контрольной суммой размера файла (разрешая переполнение), но я вполне параноик, что это может и приведет к ложным срабатываниям в наиболее экстремальных патологических случаях.Каков самый быстрый способ проверить, изменились ли какие-либо файлы в дереве каталогов?
Один вариант (безопасный) вариант Я рассматриваю сохранение манифеста каждого файла по имени и CRC32 содержимого файла. Однако этот параметр довольно медленный или медленный, чем хотелось бы, по крайней мере, для многих файлов (скажем, тысяч).
Итак, вопрос в том, какие у вас могут быть какие-то советы или рекомендации для определения того, был ли изменен какой-либо файл в дереве каталогов? Я бы хотел избежать побайтового сравнения, не отрывая слишком много надежды.
Большое спасибо за ваши предложения.
Пока программа работает, или с момента последнего запуска? – tstenner
tstenner: Если я правильно понял ваш вопрос с момента последнего запуска. Учитывая базу данных о файлах, я хочу знать, следует ли мне обновлять эту базу данных по истечении заданной продолжительности, используя только информацию базы данных в качестве ссылки. – SilentDirge
По крайней мере, если вы хотите (вероятно) обнаружить пятна в коллекции данных, тогда возьмите правильную контрольную сумму набора данных, а не только XOR. Если вас беспокоит, может ли порядок, в котором файлы возвращаются 'readdir', может измениться, хотя файловая система не имеет, вы можете сначала отсортировать файлы в каждом каталоге (и отсортировать каталоги во время обхода). Например, предположим, что я удаляю два файла с одинаковой меткой времени и создаю два файла с другой меткой времени, совершенно правдоподобно, если они временные файлы. В метрике «количество файлов и XOR временных меток» это не указано. –