What it cannot undo

The Linux build is in testing and has run only in throwaway test machines. Until it leaves testing, put it on a machine you can lose.

These are gone and are never coming back.

• Anything already sent out: a mail sent, a message posted, a payment made, data uploaded somewhere we do not see. not undoable
• The memory of a running program. not undoable
• Raw writes to a device, such as dd onto a disk or mkfs. not undoable
• Docker images. A removed image does not come back, and a container made from it waits until the image is there again.
• PostgreSQL tables that keep no change log (UNLOGGED).
• A whole PostgreSQL cluster that was dropped. This is not built.
• MySQL, MariaDB, Redis, MongoDB and other databases are not covered yet. SQLite is a file and is kept like one.
• An agent with root or sudo that sets out to remove ScriptKitty's store.

USB sticks, SD cards and disks mounted by hand are not watched until you say so with sudo sk watch DISK.

Memory disks are not watched, which means /tmp on most systems. FAT, exFAT, NTFS, network disks and ZFS are not watched either.

/var/log, /var/cache and package lists are left out on purpose. You can bring a folder back in. sk status lists every place that is left out.

A separate examiner scripts wrecks in its own sandbox VM and compares every byte, path, size, owner and mode before and after. Its wrecks are scripts and not agents. Seven of its cases are known not to come back, and in each one the go-back says so and names what it left. Three are in the list above: Docker images, tables with no change log and a dropped cluster. These are the other four.

• Files changed in place while the service was stopped. A big file on ext4 shares its bytes with its second name.
• A project inside a nested btrfs subvolume, deleted together with the subvolume.
• A file a program keeps writing through one open handle, taken back to a clock time in the middle of the writing. It is left as it is, and ScriptKitty says so. A bookmark avoids this.
• A very big file emptied by path, when the copy cannot finish in the time the system allows.

On build a3f09c7 the examiner ran 19 cases: 13 passed and 6 failed. All six are at the edges of two hard spots.

• A file a program was still making, or still held open, around the moment asked for.
• A disk with little or no room left for a copy.

Four of the six have been fixed since, and the examiner has not judged those fixes yet.

These are not refusals. ScriptKitty never blocks a change. On ext4 a file over 4 KB carries a second name, so its link count reads 2, and two things follow.

• logrotate skips such a log unless its rule says allowhardlink.
• A lock made by counting a file's names can fail. It worked in 1,200 of 1,300 tries.

This is being rebuilt so that no file carries a second name.

Deleting files on a watched disk does not give the room back while ScriptKitty holds them. In a test VM, an agent filled a project's own 256 MB disk and then deleted 203 MB of files; one sk back brought all 71 files back with no differences, but the room did not come back while ScriptKitty held the deleted files. A file that was emptied in place on a full disk (211 MB in the same test) cannot be put back, because there was no room for a copy, and the go-back says so. sudo sk free PATH lets go of what is kept for a file or folder today, but nobody has yet measured whether it gives the room back on a full disk. A plainer warning on a nearly full disk, and a command that frees room on a whole disk after showing what it costs, are coming.

A few more limits do not fit the groups above.

• A go-back to a clock time is fuzzy by milliseconds. Use a bookmark when it matters.
• While the service is down nothing is kept, and the gap is a line in the diary.
• A disk the service watches answers "target is busy" to umount until you run sudo sk unwatch DISK.
• An ordinary user can undo only what they could have changed by hand. Sudo includes everyone's changes.

Next: how it keeps things, or clouds.