aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* 0.0.12: the changelog, the checklist and the status lineHEADv0.0.12mainLukasz Kasprzak43 hours3-6/+91
|
* the applying flag is atomic; its test waits instead of pollingLukasz Kasprzak43 hours3-18/+26
| | | | | | | The race detector found my own new flag: Apply writes it on a worker and Close reads it from the main loop. The test was polling a plain field too, where the real window hears about the apply on the main loop, which orders the writes.
* a file's name is folded once, not once per name testLukasz Kasprzak43 hours4-1/+31
| | | | | | | | | | 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
* Settings changes take effect, and keep this copy respects the planLukasz Kasprzak43 hours5-3/+135
| | | | | | | | | | | | | | | | | | | | | Five of the Settings window's controls - the sort order, the three column toggles and the preview height - were read when it built its new preferences but never connected to anything, so changing them did nothing until some other control happened to fire, and then they all landed at once out of nowhere. Every control is connected now. The same closure composed a whole Prefs from its own widgets, which wrote the remembered divider positions back as zeros: dragging the panes to taste and then ticking any checkbox threw them away. A settings change is now applied over the preferences as they are, by model.Prefs.WithDisplay - which is where it can be tested, and is. "Keep this copy, replace the other" wrote a Displaces straight into the chain. internal/plan refuses to build two steps that displace one path, because the second destroys what the first put there; the window went round that code, so choosing it for two duplicates of one file left both rows saying "done" with the first file in the Trash. It now refuses the second, naming the file that has the place.
* editing one form no longer takes its neighbour with itLukasz Kasprzak43 hours5-11/+142
| | | | | | | | | | | | | | | | | | | | | | A form's span was whole lines, which is wrong the moment two forms share one. Delete: "(exclude A) (exclude B)" on one line, delete the first, both went. The dialog named one. The file still parsed, the live check said no errors and Save lit, so an exclusion could disappear silently and the next run would sort the files it had been protecting. Clear a setting: the same shape, and the Settings window walked into it itself - it writes "(defaults\n (case ignore))", so the closing paren of defaults sits on the setting's line, and putting that setting back to "default" deleted the line and broke the file it had just written. Every later change then silently reverted until Settings was reopened. A hand-written "(defaults (case ignore) (fold yes))" lost fold the same way, and that one still loaded, so it was saveable. Both now take the whole line only when the line holds nothing else, and otherwise take the form and the spaces after it. One helper, used by the main file and by a directory's settings alike.
* the window cannot pull the lock out from under a running applyLukasz Kasprzak43 hours6-8/+157
| | | | | | | | | | | | | | | | | | Close releases the directory lock and closes the log. The window could reach it while an apply was still running - saving rules, saving settings, adding a directory, or closing the window - and the engine then went on moving files with the log shut underneath: a file moved that no krino undo can see, the rest of the plan silently abandoned, and the directory unlocked while krino was still working in it. PlanTab and UndoTab refuse to close while their apply is in flight (model.ErrApplying), the window's close request and reloadEngine honour the refusal instead of ignoring it, and the tabs and Settings are greyed out for the duration so a button that cannot work says so by being unavailable rather than by an error afterwards. The test starts an apply, calls Close from another goroutine while it is in flight, and requires the refusal.
* max-read bounds what a file becomes, not only what is readLukasz Kasprzak43 hours3-8/+59
| | | | | | | | | | | | | | | | | | | | | 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 saidLukasz Kasprzak43 hours4-6/+74
| | | | | | | | | | | | | 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 symlink in the sorted directory no longer redirects a stepLukasz Kasprzak43 hours6-6/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | Placeholders were already stopped from sending a file out of the directory a rule named. A symlink is a name too, and the directory krino sorts is by the threat model's own premise a place the internet writes into: a link named after a rule's destination sent moves and copies anywhere, and under (on-conflict overwrite) trashed a file OUTSIDE the sorted directory - while the plan showed the in-tree text and the run reported success. A step whose destination passes through a symlink at or below the directory being sorted now fails. A destination the configuration names outside it - ~/docs on another disk - is the user's own arrangement and is followed as before; both cases have a test. End to end, the review's scenario (Out -> ~/secret, overwrite): before: 1 applied, the user's file replaced and trashed after: 0 applied 1 failed, the file untouched, nothing trashed Two bookkeeping bugs in MkdirAllTracked went with it: a dangling symlink read as a missing directory and was then recorded as one krino had created - undo would have unlinked a link krino never made - and a directory created by someone else between the check and the mkdir was recorded the same way.
* a duplicate test in an exclude protects like one in a ruleLukasz Kasprzak43 hours4-16/+70
| | | | | | | | | | | | 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 displacedLukasz Kasprzak43 hours5-3/+207
| | | | | | | | | | | | | | | | | | | | | | | | (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 trashedLukasz Kasprzak43 hours3-26/+140
| | | | | | | | | | | | | | | | | | | 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 suffix search continues instead of starting again at _1Lukasz Kasprzak43 hours4-13/+89
| | | | | | | | | | | | | | | Every file renamed onto one name probed stem_1, stem_2, ... from the beginning, so N files cost N^2/2 Exists calls - a test here counts 1890 of them for 60 files. The search now continues from the highest suffix already tried for that stem. Within one plan that is the same answer: the taken set only grows while a plan is built and the disk is not being written to, so a suffix taken once stays taken. Proved rather than argued - with same_1 and same_3 already on disk and same_2 free, both versions put a file in the gap, and the two plans are byte-identical. 1500 files renamed to one name: 2.63s -> 0.05s
* a content class is worked out once, not once per copyLukasz Kasprzak43 hours2-5/+98
| | | | | | | | | | | | | | | | | | Lookup walked the whole size group for every file in it, so N copies of one file cost N walks of an N-member group, each taking the index's lock at every step - which is why more workers made it slower rather than faster. Every member of a class elects the same original (the invariant identicalTo already documents and a test already pins), so the class is memoised on the first walk and every later member is a map lookup. Measured over identical files, invented data, same machine: 500 files 0.17s -> 0.12s 2000 files 1.89s -> 0.58s and the plans are byte-identical once the sandbox path is normalised. The test counts walks: one per content class, not one per file.
* the directory lock is the kernel's, not a pid we believeLukasz Kasprzak44 hours5-112/+266
| | | | | | | | | | | | | | | | | | | | | | | | | | flock(2) on the lock file's descriptor replaces "write my pid, and decide whether the pid in the file is still alive". The kernel drops the lock when the process ends, however it ends, so there is no stale krino lock to detect and no takeover to race over. What that fixes: - Two runs that both judged a lock stale could remove and recreate it and both believe they held it. Remove-then-create cannot be made atomic; there is nothing to make atomic now. Pinned by a test with eight callers over twenty rounds. - A pid reused after a crash made the lock live for ever, and the message named neither the file nor the pid, so there was nothing to act on. The message now names both. - Signal(0) reads EPERM as "not running", so a lock held by another user was taken over. There is no such judgement left to get wrong. A run that waits for a held lock now says so first. Waiting is what the spec asks for, but the wait has no timeout, and in silence it is indistinguishable from a hang - I spent two minutes on one myself today, waiting on a lock the window was holding. Tests that faked a held lock by writing a file now hold a real one.
* the module path is git.labunix.xyz/krinoLukasz Kasprzak44 hours106-227/+229
| | | | | | | | | | | 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.
* the repository has a public addressLukasz Kasprzak45 hours3-5/+12
| | | | | | https://git.labunix.xyz/krino.git, on cgit and clonable without an account. About shows it and the README's status says how to clone; go install still needs a module path that is a URL.
* the contact address is lukas@labunix.xyzLukasz Kasprzak45 hours4-4/+4
| | | | | The same address the commits are authored from, rather than a second one to keep working.
* comments that explain the code, not how it was writtenLukasz Kasprzak45 hours78-1064/+974
| | | | | | | | | | | | | | | | | | 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.
* README for a stranger: a screenshot, a rules file, and a third less of itLukasz Kasprzak45 hours2-197/+131
| | | | | | | | | | | | | | It opened with a paragraph of version history and spent 148 of its 273 lines on a walkthrough. What sells the program is a rules file and the plan it produces, so those come first, with a screenshot of the window above them. Every command and every pasted line was run again in a scratch config: the plan, the apply, the log line and the undo are this morning's real output, and the example rules file passes krino check as written (with the paths pointed at a sandbox). docs/krino-gui.png is from invented files under /tmp/krino-demo.
* gui: the path keeps its telling end, and the checklist grows three itemsLukasz Kasprzak45 hours2-2/+15
| | | | | | | | | | | Squeezed, the toolbar's path label read "/t... ds". It now elides the start, since the end of a path is the part that says which directory this is, and will not shrink below about sixteen characters; the tooltip still holds it in full. The checklist gains the reordered bar, the About block, and the sandbox trap that had every file skipped: krino's own (min-age 2m) ignores a file written in the last two minutes.
* gui: the toolbar in the order things happen, and an About blockLukasz Kasprzak45 hours7-9/+115
| | | | | | | | | | | | | | The Plan bar now reads left to right as the work does: which directory, how it should be listed, what of it, where it is on disk - then Scan, and only then what to do with what came back. Scan carries the theme's accent, being the button that starts everything. Settings ends with About: the program and the version it was built as, what it is in a sentence, the licence, and who to write to. The text is model.About so it is tested; ui.Version is stamped by main. leak-check knows krino's own contact address, so the address check stays useful without a per-clone setting.
* gui: an exclude is not a rule - the form no longer assumes onev0.0.11Lukasz Kasprzak46 hours5-12/+68
| | | | | | | | | | | Selecting the exclude row in Forms panicked: newFormEditor read the form's rule for its when, name, action and stop, and an exclude has only the when. The editor now takes the conditions from whichever of the two the form holds and leaves out the fields an exclude has not got. Checklist item 49 covers it. Also the 0.0.11 changelog and README, and header floors wide enough that the age heading is not clipped.
* gui: conditions as a nested tree, and a way to add a directoryLukasz Kasprzak46 hours10-32/+590
|
* gui: name the other copy of a duplicate, and offer to keep this one insteadLukasz Kasprzak47 hours9-16/+237
|
* gui: sort the plan by name, size, age, action or ruleLukasz Kasprzak47 hours7-21/+277
|
* gui: size and age columns, column toggles, readable colours, a laid-out ↵Lukasz Kasprzak47 hours9-88/+322
| | | | explanation
* gui: keep every divider where it is put, and let the columns shrinkLukasz Kasprzak48 hours5-31/+126
|
* gui: an applied plan says it is history; Settings says what needs savingLukasz Kasprzak2 days3-5/+34
|
* gui: aligned columns, theme colours, a second layout, and a scan-selection ↵Lukasz Kasprzak2 days6-52/+205
| | | | setting
* gui: coloured actions with headers, a filter over the plan, bulk trash or deleteLukasz Kasprzak2 days13-65/+659
|
* gui: the preview is as big as you drag it, and PDFs render to suitLukasz Kasprzak2 days6-41/+176
|
* gui: a rendered PDF page per file, and Settings in the top rightLukasz Kasprzak2 days5-7/+104
|
* gui: syntax colours, a file preview, and a settings windowLukasz Kasprzak2 days17-18/+1417
|
* gui: line numbers, a Check button, an operator for age and size, and Test ruleLukasz Kasprzak2 days4-12/+328
|
* gui: show the problems under both sub-tabs; name the operator rows; fix the ↵Lukasz Kasprzak2 days2-4/+31
| | | | list labels after an edit
* gui: size the plan and undo columns to what they hold, so the rule is never cutLukasz Kasprzak2 days2-13/+71
|
* krino-gui(1), README and changelog for 0.0.10v0.0.10Lukasz Kasprzak2 days5-6/+291
|
* gui: the directory's own settings as a formLukasz Kasprzak3 days3-6/+470
|
* gui: forms editor - rules and excludes as forms, with add, delete and moveLukasz Kasprzak3 days5-3/+1304
|
* gui: Rules tab - the file as text, checked as you type, tested and savedLukasz Kasprzak3 days5-1/+926
|
* gui: History and undo tab; each plan and undo is its own runLukasz Kasprzak3 days10-63/+1041
|
* gui: row menu for trash or permanent delete; Apply frees the directoryLukasz Kasprzak3 days3-3/+121
|
* gui: the Plan tab - scan, review, apply, with the directory lockedLukasz Kasprzak3 days9-17/+735
|
* gui module: the plan tab's model, with testsLukasz Kasprzak3 days7-2/+484
|
* unsaved text for another included directory is not an error; two keys for ↵Lukasz Kasprzak3 days2-19/+76
| | | | one file are
* milestone 1 review: claims span the run, explain's chain is opt-in and its ↵Lukasz Kasprzak3 days12-34/+380
| | | | own, overrides keyed by clean path, splice and enum guards
* config prints and splices one formLukasz Kasprzak3 days6-2/+269
|
* undo runs through the same sessionLukasz Kasprzak3 days4-51/+114
|
* the engine owns a run: lock, log, run id, claimsLukasz Kasprzak3 days3-73/+285
|