Comments 3
Забавно, что код возврата 0 здесь честнее всего: библиотека без единой ошибки сделала ровно то, о чём её попросили – поверила двум байтам. Заголовок EVTX на работающей машине – это обещание, а не отчёт: система дописывает chunk'и, а счётчик обновляет лениво, при штатном закрытии файла. Мораль: если инструмент триажа спрашивает у подозреваемого файла, сколько в нём данных, странно ждать честного ответа.
«Обещание, а не отчёт» — формулировка лучше моей, забираю)
Про «обновляет при штатном закрытии» — почти так, но чуть мягче. В том же образе есть GroupPolicy: файл dirty, то есть штатно не закрывался, а chunk_count у него верный — 5 из 5. Зато next_record_num отстал: 635 при реальных ID до 670. То есть заголовок не пишется один раз на закрытии, он обновляется рвано, и разные его поля отстают независимо друг от друга. Полагаться нельзя ни на одно — но и «врёт всегда» тоже неверно, иначе проверка была бы бессмысленной.
А вот с моралью поспорю в одном месте, и как раз в нём вся соль. Моё --verify ведь тоже спрашивает у подозреваемого файла — просто другую его часть. Разница не в том,доверять файлу или нет, а в том, как пишется конкретное поле:
— chunk_count в заголовке файла — это сводка, которую служба ведёт отдельно от данных и сбрасывает когда придётся. Отстать может на сколько угодно.
— Счётчики в заголовке chunk'а обновляются тем же действием, что добавляет запись внутрь этого chunk'а. Отстать от собственного содержимого они могут максимум на одну запись — если процесс умер прямо между записью и обновлением заголовка. Такой файл, кстати, даёт «прочитано больше, чем заявлено», и это отдельный вердикт.
Так что вопрос не «верить ли файлу», а «какое поле обновляется синхронно с тем, что оно описывает».Файл честен ровно настолько, насколько атомарна запись поля.
У молчаливой потери 4% журнала есть неожиданное юридическое продолжение.
Если оператор уничтожает персональные данные автоматизированно, подтверждением служат два документа: акт и выгрузка из журнала регистрации событий (приказ Роскомнадзора № 179). Причём выгрузка там понимается узко. Это конкретный набор сведений: субъект, категории данных, наименование системы, причина и дата уничтожения.
Парсер, который тихо пропускает часть записей и не считает это ошибкой, ломает как раз доказательство. На проверке предъявляют не журнал целиком, а выборку из него.
Разница между «прочитали 96%» и «прочитали всё» тут не про качество данных. Она про то, чем оператор докажет уничтожение конкретной записи.
Ваш подход с явным различением «не прочитано» и «прочитано пусто» для такой задачи как раз то, что нужно. Пробовали прогонять на выгрузках, где записи удаляли по ротации?
Ваш парсер .evtx молча прочитал 4% журнала — и не считает это ошибкой