# tcslog-tools 0.1.8
The library requirement, and the documentation that names it. Neither tool
changed -- not an option, not a line of output, and not which stored
segment file formats a build understands -- so a dependent upgrading from
0.1.7 sees no difference in what the binaries do.
The `tcslog` requirement moves from 0.3 to 0.4. That release added a field
to `Record`, the value `LogRead::iter` yields, saying whether the record is
a whole one or only its front. It breaks a caller that builds a `Record`
with a struct literal or destructures one exhaustively, and the requirement
moves only because a caret requirement on 0.3 does not match 0.4. A copy
built against `tcslog` 0.3, or 0.2, is equally correct and goes on working.
**The change does not reach these tools, and the reason is worth stating,
because the library release it comes from is a fix to exactly the behaviour
`tcslog-dump` reports on.** Both tools read through `LogRead::read` into a
buffer of their own; neither names `Record`, and neither calls the iterator.
What 0.4.0 fixed was the iterator handing partial records back unmarked, so
that a caller could not tell the front of a record from the whole of one.
`read` never had that problem: a record cut short arrives as
`ReadTruncated` carrying the bytes recovered, and `tcslog-dump` has always
printed those marked, with the lost-file count beside them. So the library
grew a way to say through the iterator what these tools were already saying
through `read`.
This is the release that puts the requirement and the documentation on
crates.io, `tcslog` 0.4.0 now being published; the requirement was already
correct in the repository and could not resolve from the registry until
that happened.
Requires `tcslog` 0.4.
### Changed
- The `tcslog` requirement becomes 0.4. That release adds a field to
`Record`, the value `LogRead::iter` yields, which breaks a caller that
constructs or exhaustively destructures one. Neither tool does either:
both read through `LogRead::read` into a buffer of their own, and neither
names `Record` at all. Nothing in either binary changes, and the records
they read are the same records, the stored format being unchanged at
0.1.0.
The new field says whether the record handed back is a whole one or only
its front. `tcslog-dump` already reports that distinction, because `read`
always made it: a record cut short arrives as `ReadTruncated` carrying the
bytes recovered, and the tool prints them marked. What 0.4.0 fixes is the
iterator, which handed partial records over unmarked -- an interface these
tools never used.
The requirement still has to move, because a caret requirement on 0.3 does
not match 0.4. A build of these tools against `tcslog` 0.3 is equally
correct and will go on working for anyone who has one; this says which
release they are built against from here.
- The manual's prerequisites and the README name 0.4 as the library version
these tools are built against, as 0.1.7 had them name 0.3. The
prerequisites now account for both of the library's breaking changes
rather than only the first, since a reader who meets either in the
library's own documentation has reason to ask whether it reaches these
tools. Neither does: `WriteCallbacks` is on the writing side, which is not
compiled here, and `Record` is what the iterator yields, which neither tool
uses.
### Notes
- Which stored segment file formats a build of these tools understands
follows from the `tcslog` version it was built against rather than from
this crate's: a build reads a file whose major format version matches the
library's and whose minor version is no greater. That stayed at 0.1.0
across the library's 0.4.0, so a build of these tools reads every log any
`tcslog` release has written.
- Installing: `cargo install tcslog-tools`, or `make install` from a
checkout. The tools' own documentation is `docs/tcslog-tools.rst`; the log
format they read and the recovery rules they report on are the library's,
in `docs/tcslog.rst` of the `tcslog` repository.
- The error-recovery suite in the `tcslog` repository drives both binaries
from a sibling checkout and compares their output against stored files,
which is what establishes that this release changed none of it.
- Requires Rust 1.75 or later. Dual licensed under MIT OR Apache-2.0.