v3.14.0

fastf 3.14.0: moves that finish clean on fragile mounts

Nothing about an existing project changes. Every PROJECT_INFO.md,
config.toml and template works untouched, and no command, flag or file format
was removed. Anything an older fastf left unfinished is picked up by this one:
the app finishes it by itself, or fastf reconcile does.

This release comes out of moving projects across an sshfs mount of a laptop and
an rclone mount of a Cloudflare R2 bucket. A move that met a dropped
connection, a dev server still writing, or an upload rclone had not finished
could leave half of the old copy behind, lose the record that said so, and end
with "look inside, and delete it yourself". None of that should happen now.

Only what fastf cannot fix stops a move

A move stops for a missing permission, a full or read-only drive, a name the
drive will not take, or a program holding a file in the project, and it says
which file and which program before anything is copied:
python3 (pid 4242) has session.txt open for writing; close it, or quit python3, then move again. On Windows, where a folder cannot be moved while
anything in it is open, it names the program there too, and a console sitting
in the project's folder.

Everything else is waited out:

• An input/output error or a brief lock is asked again with a growing pause.
• A mount that drops is waited for until the same mount is back. A move whose
  mount stays gone before it has published its copy pauses, keeping what
  it copied; moving the project again, or a reconcile, copies only the rest.
• A stall is said, never a freeze: no answer from /mnt/laptop for 12 s.
• A program merely running in the folder, like a dev server or your shell, does
  not stop the move. What it changes during the move is copied too, and the
  result tells you to restart it from the new place.

The old copy leaves entry by entry

Once the moved copy is complete, the original leaves the library in one step,
and what is left of it is removed only where the moved copy provably holds the
same. Something missing from the moved copy is put back into it first;
something that changed in the original during the move replaces the moved
copy's version; only a file changed in both places is kept and asked about.
On an rclone mount the old copy is emptied where it stands instead of renamed,
since a rename there is a copy and a delete of every object and moves uploads
still in flight. The record of the move is never cleared while anything it
owns is left, and on a cloud mount it stays ten minutes more, in case the
mount puts something back.

fastf finishes its own leftovers

The app runs its own reconcile when there is something it can finish, and the
header only asks for you when a decision is really yours: ⚠ 1 needs you !.
! lists everything unfinished with its reason and the choices that settle it
(keep the moved version, take the old one, put an old copy back, discard it).
From a terminal: fastf reconcile --list and fastf reconcile --resolve <path> <action>.

A base that stops answering holds up nothing

Every base is asked at once, with one short deadline. In the app each base's
projects are listed as soon as that base answers, a silent one is named
unresponsive in the header, and q quits at once. A project copied onto an
rclone base from elsewhere is listed without fastf reindex.

Faster, and truer to the original

Walks, copies and removals ask the filesystem about several entries at once.
Moving a web project off R2 went from 5 minutes 14 to 24 seconds, and deleting
one there from almost 6 minutes, with 181 files left behind, to 28 seconds with
nothing left. A move now keeps file and folder times and permission bits, +x
included, as mv does.

Compatibility

A move this version records on an rclone mount is written so that an older
fastf refuses to finish it rather than finish it the wrong way. If you run
fastf on two systems sharing a cloud base, update both.

What's Changed

• packaging: bump both AUR packages to 3.13.0-1, and retire PLAN.md by @cristocola in #107
• fastf 3.14.0: moves that finish clean on fragile mounts by @cristocola in #108
• The Windows folder-holder test holds the folder itself by @cristocola in #109

Full Changelog: v3.13.0...v3.14.0