Ваш парсер .evtx молча прочитал 4% журнала — и не считает это ошибкой

[Granulex]

Забавно, что код возврата 0 здесь честнее всего: библиотека без единой ошибки сделала ровно то, о чём её попросили – поверила двум байтам. Заголовок EVTX на работающей машине – это обещание, а не отчёт: система дописывает chunk'и, а счётчик обновляет лениво, при штатном закрытии файла. Мораль: если инструмент триажа спрашивает у подозреваемого файла, сколько в нём данных, странно ждать честного ответа.

[kotru21]

«Обещание, а не отчёт» — формулировка лучше моей, забираю)

Про «обновляет при штатном закрытии» — почти так, но чуть мягче. В том же образе есть GroupPolicy: файл dirty, то есть штатно не закрывался, а chunk_count у него верный — 5 из 5. Зато next_record_num отстал: 635 при реальных ID до 670. То есть заголовок не пишется один раз на закрытии, он обновляется рвано, и разные его поля отстают независимо друг от друга. Полагаться нельзя ни на одно — но и «врёт всегда» тоже неверно, иначе проверка была бы бессмысленной.

А вот с моралью поспорю в одном месте, и как раз в нём вся соль. Моё --verify ведь тоже спрашивает у подозреваемого файла — просто другую его часть. Разница не в том,доверять файлу или нет, а в том, как пишется конкретное поле:

— chunk_count в заголовке файла — это сводка, которую служба ведёт отдельно от данных и сбрасывает когда придётся. Отстать может на сколько угодно.
— Счётчики в заголовке chunk'а обновляются тем же действием, что добавляет запись внутрь этого chunk'а. Отстать от собственного содержимого они могут максимум на одну запись — если процесс умер прямо между записью и обновлением заголовка. Такой файл, кстати, даёт «прочитано больше, чем заявлено», и это отдельный вердикт.

Так что вопрос не «верить ли файлу», а «какое поле обновляется синхронно с тем, что оно описывает».Файл честен ровно настолько, насколько атомарна запись поля.