Development update: work in draft PR #736. VaultSync 1.9.0 has not shipped.
A mostly-code Unity project can still produce a surprisingly large backup. I went looking for the bytes before changing how they were compressed. That investigation led to better exclusions, a measured ZIP adjustment, and the first steps of a separate compression experiment.
There is visible progress too: projects imported from another machine now belong in the Projects list, with their origin and local source availability explained separately.
Imported projects have a place in Projects
An imported backup history should be easy to find even when the original source folder is on another computer. The development UI now keeps those registered projects visible and gives them an Imported label in the list and details.
The import marker describes origin. Local source availability is a separate state. Restoring or linking a folder does not erase the import marker, and an unavailable source cannot accidentally start a snapshot or open a nonexistent folder. History remains available for file recovery.
This extends the existing file-backup workflow. It does not mean the separate portable recovery or disk-imaging plans have shipped.
The Unity preset needed attention before the compressor
Unity is very good at generating files you never consciously asked it to generate. Caches are familiar; saved profiling captures are easier to overlook.
The audit found two problems. Indexed exclusion presets were not resolved consistently across the project workflow, and saved Unity profiler captures could enter a source backup. Preset resolution is now consistent, and the Unity preset includes .pdata captures alongside its cache/build exclusions.
The existing editor displays the corrected Unity rules. This is a native view capture, not a new editor design or conceptual image. The fixture contains a Library cache and a small synthetic .pdata file; the real backup path excludes both.
There is an important distinction here: leaving generated files out of a source backup changes what goes into the archive. It is not a compression-ratio improvement. Existing archives are not rewritten by this preset change, and project-specific rules still need to match what you actually want to preserve.
A compatible ZIP improvement
File archives still use standard ZIP. When compression is enabled, Unity .unity, .prefab and .meta files now use the denser existing compression level. Binary .asset files retain the previous policy.
The generated-fixture measurements make the tradeoff concrete:
| ZIP fixture | Previous bytes | New bytes | Size reduction | Encoding median |
|---|---|---|---|---|
| Scene and prefab text | 250,608 | 167,260 | 33.3% | 1.78 → 8.85 ms |
| 2,000 small metadata files | 611,529 | 562,062 | 8.1% | 9.83 → 14.45 ms |
The smaller archive takes more CPU to create. These figures come from synthetic, repeatable fixtures, not the user's Unity project or a server transfer. The full reports record the runtime, machine and source identity.
The metadata example also has a useful sting: the new ZIP is still larger than its 480,000 bytes of logical content. Thousands of file headers and paths have a cost. A small-file workload needs more than a better compression level to make that overhead disappear.
Compression remains off by default for new installations. Existing ZIP readers and the backup encryption/publication path remain in place.
Our compressor has a second prototype
Separately, I started a bounded LZ77 implementation and added canonical Huffman coding to its token stream. It checks block sizes, code tables, bit counts, padding, token distances and decoded content hashes. It chooses raw storage or plain LZ tokens when the complete entropy payload would be larger.
| Generated block workload | First prototype | With Huffman | zlib level 6 |
|---|---|---|---|
| Unity YAML | 75,999 bytes | 54,394 bytes | 38,181 bytes |
| Source code | 54,726 bytes | 36,502 bytes | 25,943 bytes |
That is a 28.4% and 33.3% improvement over my first prototype. DEFLATE is still more compact on these fixtures, and my straightforward Python entropy reader is slower. The experiment remains outside application builds and does not write anyone's backups.
The next steps are bounded match-search experiments and an independently implemented native reader, followed by differential tests, fuzzing and representative restore measurements. Any eventual writer needs readers delivered first, explicit opt-in and a safe rollback path. Old ZIP archives must stay readable.
Visible cleanup, quieter release work
The storage charts now draw through native Avalonia controls, removing the LiveCharts dependency from this desktop branch while retaining the usage breakdown.
Focused capture of the current storage card. The project figures are logical payload totals recorded for two synthetic file backups, not compressed ZIP sizes; the free-space gauge reflects the capture filesystem. This is not disk-recovery evidence.
I also repaired missing UI translations and added checks for all 19 maintained catalogs. The checks cover catalog alignment, placeholders and recognized source references; language quality and rendering still need human review.
Release preparation now uses the serviced .NET 10.0.13 runtime, with checks for every embedded Microsoft framework. The current 1.9.0 private Windows, macOS and Linux builds pass the runtime audit. Package/manifest/patch provenance checks remain part of release preparation; this does not claim new native publisher certificates or installed-upgrade qualification.
Where the beta stands
The latest complete local Release check passes 1,181 Core tests and 192 Python tests, with zero build warnings or errors. Eighteen of those script tests cover the compression experiments. These are local implementation checks, not a declaration that every release gate has passed.
Stable remains 1.8.9. The complete-feature 1.9.0 beta is still being prepared. Physical device workflows, independent boot media, the measured capture-to-restore loop, platform/installed-upgrade checks and the remaining analysis/release gates are open. The custom compressor is research, not a new production backup format.
The pictures are unmodified native renders of the actual development views with isolated demo data. Desktop capture could not connect in this session, so they are not OS screen grabs or an installed-build interaction test. No real user project, backup destination or credentials were used.
Code and evidence are in PR #736, the imported-project notes, ZIP measurements, compression plan and runtime servicing evidence.
For code-heavy projects, which files most often make your backups unexpectedly large: engine caches, profiler captures, generated builds, or lots of tiny metadata files?