0.8.0

truncate(2), and the backends that fixed the EAGAIN this port reported.

truncate (76) had no case. Only ftruncate was answered, and the two are not interchangeable to a caller holding a name and no open file — which is every caller of std::filesystem::resize_file, since libc++ expresses it as detail::truncate(p.c_str(), size). Composed as SYS_utimensat beside it already is.

Repins openkal-linux 0.7.1 and openkal-macos 0.6.1. Those correct kal_timeout_read and kal_timeout_write, which decoded a borrowed kal_stream handle with the decoder for an owned one and so waited upon the descriptor below the one they transferred upon. This port is where that was observed and is not where it was: libc++ opens a copy's source with O_NONBLOCK, do_read routes that through the bounded-transfer path, and copy_file_range is a read/write loop — so every byte of a file copy passed through the wrong wait, and EAGAIN is not in libc++'s fallback list.

A directory's modification time: reading it works and setting it is refused, and the two are now observed separately. libc++ gives both last_write_time overloads the same operation name, so a failure in either reads identically. The refusal is asserted and the value reported — it is EISDIR on Linux and macOS and EACCES on Windows, and belongs to the backend rather than to this port.

Reported in mcpplibs/openkal-linux#13. .agents/docs/2026-08-30-issue13-round-four-timeout-truncate-and-provenance.md records the round.