How it keeps things

A small background service watches the files on the machine's own disks, its Docker containers and volumes, its systemd units and a local PostgreSQL. It needs nothing from the agent: no plugin, no approvals, no prompts. It does not read command text and uses no model. It watches what the kernel does, so a delete looks the same whether it came from a shell, a script or Docker.

Linux lets a program be asked before a file is opened. The service asks the kernel to wait at every open on whole disks, using fanotify. An open for writing waits while a before-picture is taken if the file has none, and then it goes on.

Reads are never held and never written down.

The kernel offers no such question before a delete or a rename. So deletes are made harmless in advance: by the time one arrives, the file already holds an old copy or a second name.

How a file is held depends on its size and on the disk it sits on.

The store is on the same disk as the file, outside every user folder, and only root can read it.

ScriptKitty writes a diary of what appeared, vanished, moved or changed, and when. Each line also says which program did it, with its parents.

The sk command reads the diary and puts things back. One change goes back with sk undo 12. Everything as it was at a clock time or a bookmark goes back with sk back 10m, sk back 14:32 or sk back m1234, and sk mark saves a bookmark. An ordinary user can undo only what they could have changed by hand, while sudo includes everyone's changes.

The default keep time is 24 hours of fine-grained history, and sudo sk keep 3d changes it. When the keep time passes, old copies are let go.

sk space shows how much room the copies take. sudo sk free PATH lets go of the copies held for one file.

On a nearly full disk ScriptKitty gives way. The program's write goes through with no copy, and the file and the moment are named in sk status. It never refuses a change because the disk is full. Its own copies take room, so a full disk can come earlier than it would without it.

The first write-open of a big file on ext4 after each save waits for a copy of it. That wait is the cost of ext4. On btrfs and xfs the clone is free.

Docker containers and volumes, and systemd units, come back through recorded steps.

A local PostgreSQL has its own trash can. The database's own change log is kept, and tables are put back from it. That covers deleted, overwritten, emptied and dropped tables, added rows taken out, a changed shape and a dropped database. How the database was just now is saved to a file first, and the reply names that file and the command that loads it. Some database cases are not covered, and the limits page lists them.

Every undo is itself written down. A go-back ends with a bookmark of how things were just before it, and sk back to that bookmark takes the go-back back.

Next: clouds, or what it cannot undo.