«Обещание, а не отчёт» — формулировка лучше моей, забираю)
Про «обновляет при штатном закрытии» — почти так, но чуть мягче. В том же образе есть GroupPolicy: файл dirty, то есть штатно не закрывался, а chunk_count у него верный — 5 из 5. Зато next_record_num отстал: 635 при реальных ID до 670. То есть заголовок не пишется один раз на закрытии, он обновляется рвано, и разные его поля отстают независимо друг от друга. Полагаться нельзя ни на одно — но и «врёт всегда» тоже неверно, иначе проверка была бы бессмысленной.
А вот с моралью поспорю в одном месте, и как раз в нём вся соль. Моё --verify ведь тоже спрашивает у подозреваемого файла — просто другую его часть. Разница не в том,доверять файлу или нет, а в том, как пишется конкретное поле:
— chunk_count в заголовке файла — это сводка, которую служба ведёт отдельно от данных и сбрасывает когда придётся. Отстать может на сколько угодно. — Счётчики в заголовке chunk'а обновляются тем же действием, что добавляет запись внутрь этого chunk'а. Отстать от собственного содержимого они могут максимум на одну запись — если процесс умер прямо между записью и обновлением заголовка. Такой файл, кстати, даёт «прочитано больше, чем заявлено», и это отдельный вердикт.
Так что вопрос не «верить ли файлу», а «какое поле обновляется синхронно с тем, что оно описывает».Файл честен ровно настолько, насколько атомарна запись поля.
«Обещание, а не отчёт» — формулировка лучше моей, забираю)
Про «обновляет при штатном закрытии» — почти так, но чуть мягче. В том же образе есть GroupPolicy: файл dirty, то есть штатно не закрывался, а
chunk_countу него верный — 5 из 5. Затоnext_record_numотстал: 635 при реальных ID до 670. То есть заголовок не пишется один раз на закрытии, он обновляется рвано, и разные его поля отстают независимо друг от друга. Полагаться нельзя ни на одно — но и «врёт всегда» тоже неверно, иначе проверка была бы бессмысленной.А вот с моралью поспорю в одном месте, и как раз в нём вся соль. Моё
--verifyведь тоже спрашивает у подозреваемого файла — просто другую его часть. Разница не в том,доверять файлу или нет, а в том, как пишется конкретное поле:—
chunk_countв заголовке файла — это сводка, которую служба ведёт отдельно от данных и сбрасывает когда придётся. Отстать может на сколько угодно.— Счётчики в заголовке chunk'а обновляются тем же действием, что добавляет запись внутрь этого chunk'а. Отстать от собственного содержимого они могут максимум на одну запись — если процесс умер прямо между записью и обновлением заголовка. Такой файл, кстати, даёт «прочитано больше, чем заявлено», и это отдельный вердикт.
Так что вопрос не «верить ли файлу», а «какое поле обновляется синхронно с тем, что оно описывает».Файл честен ровно настолько, насколько атомарна запись поля.