v0.5.4 — the program itself, and what will not move

The plan now contains the program

Its executable and the library beside it were missing from the plan to remove it, while the
recording had named both four different ways. The footprint was read off the disk at plan
time, which works exactly once — on the machine that still holds the files, before anything
has removed them. On the session this was measured against, an antivirus had quarantined
both between the recording and the plan, so the listing returned two files and the two that
had done all the work were gone.

The recording is the source now; the disk only ever adds to it.

• Every module the program loaded that Windows does not own. The strongest thing a
  recording says about what a program consists of, and the only signal that reaches a
  library side-loaded from somewhere it should not be.
• Every file in its directory the recording shows being used — loaded, read, written —
  as opposed to merely opened.

That last distinction does more work than it sounds like. The loader tries the application's
own directory first, so resolving imports opens a dozen Windows library names inside the
program's folder, for files that never existed — one of them cmd.exe, wearing a path
under the operator's profile that passes every check written to recognise a system location.
Thirteen probes rejected on the measured session, four real files kept.

It is also the same answer on every machine now. Observations are tokenized when written, so
a session recorded under one profile and read under another had the footprint resolving to
one form of the path and the recording to another — two strings that never met.

A folder has to be earned. Reading the directory finds what a program shipped and never
touched, which no recording can name. It also finds everything else in there, and a program
run straight out of a downloads folder has a "directory" that belongs to the operator. So
the proportion decides: most of the folder the program's, and the rest goes with it; a
minority, and nothing is taken but what the recording named.

What will not move

A locked file said "in use or locked" and stopped, which is nothing an operator can act on.
The Restart Manager knows what is holding it, so it is asked — and most of the time that is
the whole answer, because most of the time it is a preview pane.

Past that, a second pass you ask for, never automatic: clear the attributes that are
bookkeeping rather than protection, stop the processes holding the file, take ownership
where access is denied, and hand anything still immovable to the session manager to move
before anything else starts at the next restart.

Nothing on that ladder deletes. The restart-time move goes to quarantine like every other,
so a removal that finishes after a reboot is as reversible as one that finishes straight
away. Anything Windows marks critical is left alone.

Watching it happen

Every item carries its own status as the run proceeds — waiting, working, removed, kept, at
restart, in the way — with what stood in the way written beside it, and an offer to try
harder on whatever is left.

Also fixed

• The rollback journal was an exclusive handle held for the runner's lifetime, so a second
  run against the same quarantine folder threw before doing anything — precisely the run
  that retries what the first could not finish.
• A folder that could not be removed said only that it was not empty. It now names what is
  still in it.
• Progress reports described an item rather than carrying it, so several values under one
  registry key collapsed onto a single row.
• Plan and remediation state is cleared when a session or package is loaded, and export is
  guarded when the plan came from an imported package.

Download

CaYaTrace.exe — self-contained, no .NET install needed. Windows 10/11 x64.

SHA-256: EFC1324BB5F581A3BB9A30706A5ED7DF566F1E6E378AE041B8FBF55CAFC10115