krino.git/internal/engine, branch mainrule-based file sorter in Go, shows the plan before touching anything, applies only the files you choose, and can undo any run, with s-expression rules and a GTK 4 windowhttps://git.labunix.xyz/krino.git/atom?h=main2026-09-17T12:17:54Za file's name is folded once, not once per name test2026-09-17T12:17:54ZLukasz Kasprzaklukas@labunix.xyz2026-09-17T12:17:54Zurn:sha1:b66850cc8c584cc00bcd796eb3aa238bcf87394a
Folding is the expensive half of a name test on a name with diacritics,
and every name test of every rule folded the same name again: on Polish
names it was most of the matching work. The per-file facts memoise it,
which is where one file's work belongs - the object is per file and per
goroutine, so no lock.
4000 Polish names, twelve rules with name tests: 0.33s -> 0.13s
max-read bounds what a file becomes, not only what is read2026-09-17T12:07:37ZLukasz Kasprzaklukas@labunix.xyz2026-09-17T12:07:37Zurn:sha1:4c6fadfab5434317357ad0272ace7927d2945942
max-read gates on file size before reading, then the text was read
whole and decoded: a file that is not valid UTF-8 decodes one byte per
code point and doubles, and normalising and folding copy that again per
set of options, with GOMAXPROCS files in flight. Twelve 40 MB files
reached 3.3 GB - enough to put a laptop into the OOM killer, with no
attacker involved, just a few big .log or .csv files.
Two bounds. The decoded text is cut to max-read at a rune boundary, so
the ceiling means what a reader takes it to mean. And extraction of
files at or above 4 MiB is rationed to two at a time, since holding
several large texts at once is what multiplies the ceiling; smaller
files, which is nearly all of them, are untouched.
twelve 40 MB files: peak RSS 3294 MB -> 728 MB, wall 27s -> 46s
two thousand small files: 0.05s both ways
The wall-clock cost falls entirely on large files needing extraction,
and buys a program that finishes instead of being killed.
{now} is the start of the run, as the spec always said2026-09-17T12:03:44ZLukasz Kasprzaklukas@labunix.xyz2026-09-17T12:03:44Zurn:sha1:33d771438f1da363af7c9ff2d5f4c368c326e84d
The clock was read once per directory, so a run of several directories
stamped several different times - and a review that took a few seconds
could put one run's files into two folders, or at midnight two dates.
The spec (§7.3) says "the start of the run"; krino.conf(5) documented
the behaviour rather than the intent, so the two contradicted each
other.
The session now carries the run's clock and every directory plans with
it. Engine.Plan keeps its meaning for a caller with no session of its
own; Session.Plan passes the run's own start.
a duplicate test in an exclude protects like one in a rule2026-09-17T11:59:52ZLukasz Kasprzaklukas@labunix.xyz2026-09-17T11:59:52Zurn:sha1:b44222fc2b061382dc601014cde287cc41b857ca
The scopes that drive "no rule deletes a file krino found to be a
duplicate" were collected from rules only. A directory whose duplicate
tests lived in (exclude ...) forms had no scopes at all, so the
protection never engaged: krino explain said "yes duplicate" and the
next rule permanently deleted every copy. The README's promise was
false in that shape, and the spec's wording permitted it.
What matters is what krino knows, not which form taught it. The spec
and krino.conf(5) now say so too.
a chain that deletes itself still gives back the file it displaced2026-09-17T11:58:25ZLukasz Kasprzaklukas@labunix.xyz2026-09-17T11:58:25Zurn:sha1:9ab6686b98499c745024a474a71e3d99b6e14973
(on-conflict overwrite) trashes the file in the way; §7.4 promises undo
restores it. Walking a file's log entries stopped dead at a permanent
delete, so the displace written earlier in the same chain was never
reached: the user's file stayed in the Trash, the refusal named only
the file they did not care about, and krino log called the run undone.
The displaced file is a different file, so it is offered as its own
entry in the undo plan, keyed by its own path - the deleted file stays
refused, since nothing of it can come back, and the copy or move that
preceded the delete stays unreversed too (undoing a copy whose original
was then deleted would destroy the last remaining copy).
The accounting matched: every reversible step of a deleted file was
subtracted, its displace included, so the run read (undone). Only what
genuinely cannot come back is subtracted now.
End to end, the scenario from the review: the only copy of a file is
displaced by an incoming one that is then permanently deleted.
before: archive/ empty, "(undone)", nothing offered
after: archive/a.pdf restored, run reads partly undone
a file trashed to make room is logged the moment it is trashed2026-09-17T11:53:01ZLukasz Kasprzaklukas@labunix.xyz2026-09-17T11:53:01Zurn:sha1:a80d470cbad7335fd5e534f32d935e5a49aadb24
The displace was carried out first and logged only when the whole step
finished - for a copy or a cross-device move, the entire data transfer
later. A process killed in that window left the user's file in the
Trash with nothing recording it: krino log said "nothing applied" and
undo offered nothing.
It is its own action with its own line (spec §9), so it is now written
the moment trash.Put returns, through a hook ChainLogged calls before
the step that needed the name begins. A displace that cannot be logged
fails the step rather than compounding an unrecorded destructive act
with a second one.
Verified by killing krino -9 mid-copy with 600 MB in flight:
before: krino log "nothing applied", 0 displace lines
after: krino log "1 displaced", 1 displace line
the module path is git.labunix.xyz/krino2026-09-17T10:54:06ZLukasz Kasprzaklukas@labunix.xyz2026-09-17T10:54:06Zurn:sha1:1884d56b0d399e9cdb80016a9c166b0120989933
So that go install can find it. cgit serves no go-import meta tag, so
nginx answers a ?go-get=1 request for /NAME with one pointing at
https://git.labunix.xyz/NAME.git; the alternative was carrying a .git
suffix through every import line forever.
One sed over the imports, both go.mod files, and the dependency gate's
whitelist. Nothing else depends on the path. go install works from the
next tag, the first release whose go.mod carries it.
comments that explain the code, not how it was written2026-09-17T10:11:42ZLukasz Kasprzaklukas@labunix.xyz2026-09-17T10:11:42Zurn:sha1:bddbd74e4a73e8e32bcf648efd1cac5655f6d0cd
About 340 comments cited the development process: task and plan
numbers, fix waves, rulings, reviewers, and the author in the third
person with a date. None of that exists outside the work itself, so to
a reader it pointed at nothing. Each one now states the engineering
reason it was standing in front of; where a comment was provenance and
nothing else, it is gone.
References to docs/design.md and docs/gui-design.md by section stay:
both ship with the repository. The design documents lose their
amendment diaries - CHANGELOG.md is that record - and the GUI's says
plainly that the window has gone further than the document.
Only comments changed. Every .go file was parsed and its code printed
with comments stripped, before and after: the two hashes are identical
across all 175 files.
gui: name the other copy of a duplicate, and offer to keep this one instead2026-09-17T08:15:45ZLukasz Kasprzaklukas@labunix.xyz2026-09-17T08:15:45Zurn:sha1:a2cb20851499e9c00bd3bf642680a9ce3148cae8gui: History and undo tab; each plan and undo is its own run2026-09-16T07:39:59ZLukasz Kasprzaklukas@labunix.xyz2026-09-16T07:39:59Zurn:sha1:6ef83d6bdfb6120f9e1fbd145e0bc463196103d1