It feels like a good time for a longer look at 1.9.0. The last few updates covered individual pieces: imported projects, Unity presets, navigation, and the first compression experiments. Those pieces now need to come together, because the goal is a beta containing every feature planned for this release, with something useful to test behind each one.
The beta is not available yet. This work is on the 1.9.0 preparation branch, in a pull request that remains a draft. This is the pre-beta diary: what is already implemented, what the tests have uncovered, and what still needs to happen before there are packages to download.
I'll start with the things you can see. Then we'll get to the things a backup application really shouldn't get wrong behind the scenes.
A project shouldn't disappear because it started on another computer
If I import backup history from another machine, I expect to find the project under Projects. I don't want to remember which corner of the application it ended up in.
The development view now keeps registered projects visible even without a local source folder, with an Imported badge in the list and details. Origin and local availability are separate facts: linking or restoring a folder doesn't erase the fact that a project was imported.
Actions that need an unavailable source stay disabled. History remains available for file recovery. It's a small change to describe, but it makes using the same backups across computers less ambiguous.
Development capture prepared for the October 14 diary: a native render of the real interface using synthetic projects and temporary folders. Reused here for the pre-beta recap; this is not a fresh capture or disk-recovery qualification.
Before compressing better, decide what belongs in the backup
The Unity preset investigation started with a practical question: how does a mostly-code project end up with such large backups?
I hadn't measured the reported project on the destination server, so it wouldn't be honest to attribute all those gigabytes to one cause. The code audit did find concrete problems, though. Preset resolution wasn't consistent across the workflow, and saved Unity profiler captures could enter a source backup.
Resolution is now consistent, and the preset includes .pdata captures alongside its cache and generated-file exclusions. Those rules still need to reflect what you want to preserve. A preset cannot independently decide which build outputs matter to a particular project.
Native view capture from the earlier diary, using demonstration data. It shows corrected rules in the existing editor, not a new interface or a measurement of the project on the server.
Exclusions change which files enter a backup. Compression changes how much space the chosen files occupy. Keeping those separate avoids calling an archive “better compressed” when we've simply stopped including a cache.
Back should remember where we were
Another part of the work is navigation: Back and Forward buttons, Alt+Left and Alt+Right shortcuts, and resuming the last page on startup.
The useful test was leaving History, opening Settings, and returning without losing filters or unfinished work. That uncovered a defect too: refreshing History could rebuild the selection and discard draft snapshot labels, notes, and tags. Drafts are now preserved for the same project and snapshot during the session.
The opening image shows that development History view. The demonstration point is Metadata only: it describes existing metadata, not already recoverable file content. I want the application to explain that difference, even when the answer looks less reassuring than a big green tick.
The less visible part: before the first write
The newest work is inside the Linux disk-recovery engine. There isn't a new recovery screen to show for this increment, but there is an important boundary to get right.
Checking an image once is insufficient if the bytes eventually written can change afterward. The updated path asks a separate reader to inspect the input before reserving storage for a private copy. After copying, the engine flushes its writes, closes its writable handles, and reopens the same files read-only. The reader inspects that copy again. Its findings must match, including a SHA-256 hash of the entire payload.
The component preparing the write also checks the bytes held open for that operation. A complete read-back of the destination must match the verified payload afterward. The writer can compare bytes and hashes without interpreting image structures again.
If the reader is missing, fails, or exceeds its deadline, the operation is refused. There is no fallback that quietly moves parsing into the main component.
An explanatory diagram of the implementation under development. This is not an app screenshot or proof of recovering and booting an operating system.
A bug that was better found now
One test deliberately changes a file after preparation. The expected outcome is straightforward: detect it before writing anything to the destination.
It found a real defect. A 128 KiB read buffer could retain old bytes across a seek. In one case, the initial check saw those old bytes and writing began. Final verification caught the mismatch and reported failure. Recovery wasn't reported as successful, but refusal came too late.
I've removed that buffer from the native read-only reopens. Repeated metadata and payload mutation tests, with both 512-byte and 4096-byte sectors, now refuse the operation with zero destination writes and close the target handle.
This was reproduced in the development path using synthetic data and a disposable VM. No personal disks were involved. For once, the progress bar staying at zero was exactly the result I wanted.
Compression and diagnostics have different jobs here
There have already been targeted changes to the existing ZIP policy. On a local generated scene-and-prefab text fixture, the archive went from 250,608 to 167,260 bytes: about a third smaller, at the cost of more compression time. That's a result for that fixture, not a promise about every Unity project. Existing archives weren't rewritten.
The custom compressor remains a separate experiment. Its first prototype compresses less densely than DEFLATE on the measured samples, so replacing an established format today just to have our own would make little sense. That research continues in the background while I finish 1.9.0.
There's also diagnostics work to make beta testing useful: errors, application exits, and UI hangs, not only crashes. The policy for builds compiled specifically as beta starts structured technical sending enabled, while respecting a previous refusal and keeping review, disable, and delete controls. That beta default does not transfer into stable builds.
Reports have a fixed field allowlist and bounds: no raw logs, memory dumps, project content, paths, credentials, or persistent user, device, or session identifiers. The final beta package still needs its own qualification. This isn't permission to collect everything the application can see.
So, what's left?
The latest Release check, recorded on October 22, passed 2,061 Core tests and 285 Python tests, with no warnings, errors, or skipped tests. A dedicated Linux VM run passed 36 cases for the isolated reader and private image preparation. The reported PR checks and Sonar quality gate also passed for the verified commit.
Those results are useful, but the 36 cases use an in-memory restore target and a journal fixture. They establish boundaries and refusal conditions, not filesystem recovery or a bootable operating system. Matching hashes establish matching bytes; they don't establish that a computer will boot.
Before the beta, write-worker authorization and exact destination confirmation still need completing, along with independent bootable recovery media, its interface, and the full capture, validation, boot, and restore loop. Interruption tests, installed upgrades, signed packages, and the required reviews also remain.
The four candidate profiles are GPT/UEFI with ext4 or NTFS, using 512-byte or 4096-byte sectors. None is release-qualified yet. There isn't a beta date to announce in this diary.
The goal is the complete 1.9.0 feature set. Other milestones in the 1.9 family retain their own releases. I'd rather use this pre-beta update to show where things stand and collect useful questions than make a partially checked recovery path look finished.
If you've had to recover a disk for real, what information did you most need before confirming which destination to overwrite?
Code, evidence, and limits: PR #736 · Recovery test evidence · Compression measurements · Diagnostic policy