<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - journalctl and parsing corrupted journals" href="https://bugs.freedesktop.org/show_bug.cgi?id=55239#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - journalctl and parsing corrupted journals" href="https://bugs.freedesktop.org/show_bug.cgi?id=55239">bug 55239</a> from <a class="email" href="mailto:nmiell@gmail.com" title="Nicholas Miell <nmiell@gmail.com>"> Nicholas Miell</a> <pre>It should recognize portions of the file are corrupted and start searching for magic numbers indicating a record from that point. When it finds a candidate magic number, it should check the record's checksum at the known offset from the magic number to verify it actually found a record and not just a spurious magic number. Once it finds an intact record again, it should continue parsing journal records as normal (until the next corrupt region, if any). ObjectHeader has 6 reserved uint8_t's to use for the magic number and checksum, so this would be a compatible change. Then you could make a tool (or just modify journalctl) that takes a damaged journal as input and converts all the damaged regions into artificially generated log entries saying something like MESSAGE="Damaged Region #1" with an attached DATA=the original corrupted binary data. Essentially, journalctl's current behavior of pretending the journal file ends at the first damaged region is unacceptable.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>