Append Only Journal With Recovery

A plain "append a line to a log file" journal has no way to tell a genuine record from a half-written one. After a terminal crash or a power loss mid-write, the next read either has to throw away the whole file (too conservative, loses real history) or silently trust a torn line as real data (actively dangerous for anything used to reconstruct trade state on restart). Every record this library writes is [4-byte magic marker] [4-byte length][payload bytes][4-byte checksum], flushed to disk immediately with FileFlush() so a record does not sit invisibly in a write buffer waiting to vanish. On replay, each record is independently verified: the length field is sanity-bounded, the payload byte count must match exactly, and the payload's own checksum must match what was stored - a record failing any one of those checks is corrupt and is skipped, not trusted. The magic marker is the piece that makes SKIPPING actually work rather than just detecting a problem. Once a record fails its check, its length field can no longer be trusted to say how many bytes to skip past it - so replay instead scans forward byte by byte for the next occurrence of the marker, resynchronising onto the next genuine record boundary. This is what lets one corrupted record in the middle of the file - or a torn tail record left by a crash mid-write - fall out cleanly while every record before and after it is still recovered, rather than one bad record silently hiding everything that follows it. Notes and limitations - The checksum is a simple djb2-style rolling hash, not a cryptographic digest. It reliably catches the corruption patterns a crash actually produces (truncation, a stuck or repeated byte, a partially-flushed sector) but is not designed to resist deliberate tampering. - AOJ_MAX_RECORD caps a trusted length field at 65536 bytes - a length field claiming more than that after a torn write is treated as corruption rather than a legitimately huge record. Raise the constant in the header if you genuinely need larger records. - Replay() opens its own independent read handle, so it can safely run at any time, including while the append handle is still open from an earlier Open() call in the same session. - This is an append-only log, not a database - there is no update or delete of an existing record, and no indexing beyond sequential replay. It is meant for an event/audit trail, not a keyed data store. - Multiple terminals or EAs writing to the SAME file concurrently are not coordinated by this library - pair it with a locking mechanism (e.g. FileLeaseLockManager.mqh, a separate library in this catalogue) if more than one writer can touch the same journal file at once.

Script · MT4 · v1.0 · Free

Tags: MT4 Script · MQL4 Source Code

MQL4 & MQL5 scripts · PolyMaria