Repository navigation
keeper 0.6.1
Nothing you already have stops working, and there is nothing to migrate.
An archive culled with 0.6.0 opens in 0.6.1 and keeps its tags, its bin and
its placements.
One thing is worth doing by hand: if your archive holds heic or tiff, run it
once with --rescan. Those two never decoded before, so there is nothing on
disk for them yet.
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 started as two black squares in a shelf and a quick look card that opened
onto nothing. Both are fixed. Then five sweeps went looking for what else was
under them, and the worst thing they found was not either screenshot.
| 0.6.0 | 0.6.1 | |
|---|---|---|
| a thumbnail cut off by a kill mid scan | black for the life of that folder, and no rescan ever repaired it | rebuilt on the next scan |
| that same empty file, served | 200, and a blank tile | 404 |
| a tile with no thumbnail | the browser's broken picture glyph, and no word | one retry, then no preview and the reason |
| a photograph moved in the finder while keeper is open | a black card with the size and the path floating in it | that file is not where keeper left it |
| a file that is there and cannot be drawn | the same black card | its own sentence, because it is a different problem |
| every photograph off an iphone | a black tile reading unreadable | drawn, and it opens |
| a tiff | the tile looked right and the frame would not open | drawn, and it opens |
| select all, press one tag key, 2,200 frames | 834 of the 2,200 thrown away, undo empty, the wall saying they all landed | one request, all 2,200 on the disk |
| the same key on 20,000 frames | the tab pinned a core and never came back | 20,000 rows on the disk in one second |
| a write that could not be sent at all | an unhandled error, no rollback, no undo | rolled back, and the corner says so |
| a decoder that wedges on a damaged file | held the whole scan for 521 seconds | gives up at 120, like every other call |
| duplicating an archive in the finder | the copy was refused, pointing at a window showing another folder | it opens |
| cancelling the folder chooser | an applescript error, at somebody who changed their mind | nothing |
| automated tests | 27 | 42 |
Every number there was measured on this machine, twice: once against 0.6.0 to
see the fault, once after to see it gone. Ten of the fourteen new tests fail
against the code they replace.
What it costs. A relaunch on a folder keeper has already scanned pays
about half a second more at twenty thousand frames, 2.4 seconds against 2.9,
because it now reads twelve bytes of every thumbnail instead of asking whether
a file is there. At two thousand it is 291 milliseconds against 306. That is
the price of never again having a tile that is blank for good.
what is still open
Said plainly, because five people are about to use this.
- Opening a second folder while a bulk keep is still being written puts the
writes into the wrong archive. There is a one to three second window after
select all and a keystroke. On two copies of one shoot it emptied the
untouched one's index. Do not switch folders straight after a bulk action. - Delete reports success when it cannot read the file. A folder whose
permissions changed under it drops the frame from the index while the
photograph stays on the drive. - Renaming a folder inside your archive loses every star under it. A
frame's identity is its path, and nothing reconciles the old one. - There is no way to rescan from the window. It is
--rescanon the
command line or nothing, which also means a photograph added to an open
folder never appears. - 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,
doctorcannot run to tell you so. - Opened from its icon the app cannot see ffmpeg, so clips have no poster
frame even after you install it. - Nothing has ever run on windows. It is still not notarised.