keeper 0.6.0

Nothing you already have stops working, and there is nothing to migrate.
An archive culled with 0.5.1 opens in 0.6.0 and keeps its tags, its bin and
its placements. keeper writes one new file beside them, run.json, which says
which keeper has the folder open, and one .json.bak next to each sidecar,
which is the copy it falls back on.

curl -L -o ~/Downloads/keeper.tar.gz https://github.com/gntrs/keeper/releases/latest/download/keeper-macos-arm64.tar.gz
tar -xzf ~/Downloads/keeper.tar.gz -C /Applications

This is the release that stops keeper losing your work. Everything else in it
is downstream of that.

	0.5.1	0.6.0
automated tests	0	27
a write killed mid flight	tags.json left at 6,291,456 bytes, unparseable, and the page then said 0 tags with no error	11 bytes, parses, still holds the old value
the same write on a full disk	2,621,440 bytes, unparseable	refused, file untouched
two keepers on one archive	78 of 80 stars gone, every response 200	the second is refused, and the sentence names the port the first is on
keeper tag run beside the page	80 rows became 3, every tag letter gone	every row and every star survives
a star you set, on a frame an agent's sheet covers	wiped, and the terminal said tagged 4 frames	kept
a website you are visiting posting to keeper	accepted	403, on the origin and on a per launch token
export when you deleted the sidecar	the jpeg was silently replaced, and it said wrote 1 crop	steps to a new name
two exports at once	both picked the same name, one file survived	the disk decides, the loser steps on
crops written inside the archive	the next scan indexed them as new frames	refused, with the reason
icon launch on a cold folder	nothing here yet, still blank nine seconds after the scan finished	the scan is on screen, then the shelf
your second ever launch	new in this keeper, you have probably worked most of it out already	the eight walkthrough cards, once
a folder keeper cannot write	EACCES: permission denied, mkdir	a sentence
the object-position css on the bench	only if you had written a keeper.config.json, so nobody ever saw it	always, with a copy button
the zoom readout on a fresh crop at cover	67%	100%
shelf and tray at 800x600	the page scrolled, 675 into 600	no overflow
the shortcuts sheet at 800x600	its tabs and close button at y = -43, above the top of the window	reachable
keycaps in that sheet	two rows overran their box by 11px, at every size	none
brand rules broken	5	0
keys with no route in the interface	7	0
what borders the quick look picture	warm chrome, rgb(29,25,21)	rgb(0,0,0)
the filter chips at 800 wide	474px tall, chrome eating 434 of 600 before a photograph	a sidebar that scrolls
the icon, when the remembered folder went read only	bounces, spins for 20 seconds, quits. no window, no sentence, for ever	the empty page, and the reason in the log
the folder chooser	never came to the front, while the page said it had	comes forward
the first seconds of a cold scan	the progress bar and "found no photographs" drawn on top of each other	the scan alone
a folder renamed or unplugged while open	900 broken image icons and no word	a sentence naming the folder
the privacy notice in the dmg	a hidden dot file	visible

what we did not have, and now do

Your archive survives being interrupted. Every write went straight over
the file it was replacing, so a keeper killed at the wrong moment left an
unreadable tags.json, and the next launch read that as no tags at all and
made it permanent. Writes now go to a temp file, get flushed to the disk,
and are renamed into place, which the filesystem does in one step, and the
previous copy is kept beside it. A file keeper cannot read now stops the
archive at the door and tells you which backup to look at, instead of quietly
starting again from nothing.

One keeper per folder. There was nothing stopping two, and two of them
silently overwrote each other's work: measured, 78 of 80 stars gone with every
request answering 200. A keeper now claims the folder while it holds it, and
a second one tells you where the first is instead of joining in. A claim left
behind by a crash is swept, and a claim whose port does not answer is not
believed, so a .keeper folder that travelled with your photographs to
another machine cannot lock you out.

keeper is no longer reachable from the web page you happen to have open.
Any site could post to it and have your photographs copied somewhere it chose
the name of. Every request that changes anything is now checked twice, on
where it came from and on a token minted for that launch, and neither is
something another page can get hold of.

The bench finally shows you the thing it is for. The line of css that
reproduces your crop was behind a config file, so anybody who had not written
one had never seen it, which is why the board is the least used screen in the
app. It is always on screen now, there is a button that copies it, and every
export writes a .css beside the crop with a rule you can paste.

The first minute makes sense. Opening from the icon showed an empty shelf
that never filled in, because nothing on the page asked whether a scan was
running. It shows the scan now, then the shelf. The walkthrough runs for
somebody who has never seen keeper rather than on their second launch. No
screen tells you to run a command that is not on your PATH.

It looks like a mac app. The wall of filter chips is a source list on the
left that scrolls on its own, the top is a real toolbar that does not wrap,
and the photographs get the rest of the window. Two zones still hold: nothing
warm touches a photograph anywhere, and the quick look is pure black on all
four sides of the picture at every size.

There are tests. 27 of them, node --test test/, no new dependency. Six
reproduce a way keeper used to lose work, and each of those six was confirmed
to fail against the old code, which is the half that usually gets skipped.

what got more expensive

Every write costs more, and the cost is a real one. Flushing to the disk
and keeping a backup is three operations where there was one:

tags.json	before	after
100 rows, 4 kB	0.12 ms	4.02 ms	33x
8,000 rows, 327 kB	1.52 ms	6.06 ms	4x
60,000 rows, 2.5 MB	9.78 ms	16.41 ms	1.7x

Most of that is a fixed cost, the flush, which is why the smallest write looks
worst and the largest barely moves. At the size a real archive reaches it is
about six milliseconds, against a file that used to be destroyed outright by a
badly timed ctrl c. It is the right trade and it is not free.

Your sidecars take twice the disk, because each one now keeps its last
good copy beside it. On a 2.5 MB tags.json that is 2.5 MB.

Opening a folder costs a little more. A claim file is written, and when
one is already there, a request to the port it names with half a second to
answer before it is treated as gone.

what we still do not have

Nothing in this release ran on windows. 527 lines of platform code have
still never been executed there, and the two known windows defects, the drop
panel and photographs not loading, are still reasoned about from a mac rather
than reproduced. One concrete mechanism was found for the second and the
parsing was fixed, unverified.

It is still not notarised. Your mac still says the developer cannot be
verified, and the two curl lines above are still the way around it. The
signing is ad hoc, Gatekeeper rejects the app, and the bundled node carries an
entitlement Apple rejects outright, so this is more than a certificate away.

No test touches the browser. The 27 are the server, the store, the claim
and the crops. The interface was verified by driving a real browser by hand
at seven window sizes, which is not the same as something that runs on its own.

Two known faults are still open, both cosmetic. Trashing a photograph you
had already moved yourself reports it as trashed, which is the wrong sentence
for the right outcome. And a keeper killed in the middle of writing a crop
leaves a zero byte file behind, which nothing tidies up.

Three rough edges in the new sidebar, named rather than hidden. The only
filters sit below its fold on a short window. Below 900 pixels wide with the
tray open the sidebar hides itself, so the key that opens it appears to do
nothing. And at 800 pixels the counts lose their words and read as three bare
numbers, because that is all the room there is.

Why keeper reads your Desktop and Downloads without asking was not
established. It may be a permission this machine already granted, or it may be
that a background process gets a quieter pass. A genuinely first ever launch on
a clean mac may put a dialog up that nobody here has seen.