keeper 0.6.2

Nothing you already have stops working, and there is nothing to migrate.

This one is about the seam where the folder changes under keeper: opening
another one, renaming one, or deleting out of one. Everything below was found
by going looking, not by anybody hitting it, and every number was measured on
this machine twice, once against 0.6.1 and once after.

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

	0.6.1	0.6.2
open another folder a second after a bulk keep	240 tag writes left the first archive holding 1 row of 30, and put 30 of its ids into the second	all 30 stay where they were meant to go
the same, on the bin	2 of 200 survived	200 of 200
a delete queued when you switch, on two copies of one shoot	the archive nobody touched had its index emptied and its bin destroyed	it is not touched
delete when keeper cannot read the file	trashed 1, the photograph still on the drive, the frame gone from the index and the bin	the frame stays, and it says so
rename a folder inside your archive	every star, tag, bin entry, placement and tray membership under it, gone, silently	carried across
a case only rename	the same folder to the drive, a different one to keeper	carried across
adding photographs to an open folder	they never appear	look again
a rescan from the window at all	there was none, at all	look again, under the folder name
clips, from the app icon, after you install ffmpeg	no poster, no reason given, while a terminal worked	found
the first finder prompt on a clean mac	keeper wants to control finder	a sentence saying which three things and why
automated tests	42	59

the rename, and what it will not do

A frame's identity is a hash of its path inside the archive. That is what lets
a folder grow without every decision sliding onto the wrong photograph, and it
is not changing. What it cost is that a rename made every id underneath new.

A rescan now reconciles. A frame that left the index is matched to a frame that
arrived when they are the same file name at the same byte count, and only when
both halves are unambiguous. It will not match on a name alone, because two
shoots off one card hold the same names. It will not choose between two
candidates, because there is no honest way to say which of them your star
belonged to. It will not carry onto a frame that already decided something for
itself. When it cannot be sure, it does nothing, and your decision is still on
the disk where it was.

what is still open

• Dropping a file that is not a folder onto the window opens the folder chooser
  behind it, and there is no way back except a reload.
• Twenty thousand frames scrolls at fourteen frames a second. Two thousand
  scrolls at a hundred and forty. There is no virtualisation.
• Two of the eight walkthrough cards point at something you cannot see, and the
  walkthrough does not appear at all if an update is waiting.
• If sharp will not load on your machine, doctor cannot run to tell you so.
• A tray export killed part way leaves one truncated photograph, and running it
  again writes the good copy under a different name and leaves the broken one
  under the natural one.
• Exporting a tray twice into the same folder duplicates every photograph and
  reports it as work done.
• "out": "~/Desktop/crops" in a config makes a folder literally called ~.
• Nothing has ever run on windows. It is still not notarised.