VaultSort 5.4.0-beta.160

What's New

• Your recovery code can now cover files you encrypted before you had it. A recovery code was only ever written into a file at the moment it was encrypted, so everything encrypted before you set one up stayed hardware-key-only forever and nothing in the app could change that. Key Sync now shows which of your files that applies to, and a new action beside it adds a recovery slot to them — unwrapping each file with a key you have, rewriting it with the code included, and then proving the new slot actually opens the file before moving on. (You need a security key present for the sweep, since that is what opens the files to begin with. Files that already carry a slot are skipped.)
• The Vault previews video. Alongside images, PDFs and text, you can now watch a video without exporting it out of the Vault first — it plays decrypted in memory, scrubs normally, and is dropped the moment the Vault locks. MP4, M4V, MOV and WebM are offered; MKV, OGV and AVI are not, and an HEVC video reaches the player and then tells you it cannot be decoded here rather than failing silently. Files up to 128 MB.
• After a shred, VaultSort offers to clear free space — but only where that would reach anything. When a delete leaves the original contents somewhere in free space, you are now told so, and offered a fill on the drives where filling free space physically overwrites them. On flash, where the drive decides which cells back an address and the fill lands elsewhere, it is not offered, because it would not do what its name says. The offer names the drives, asks once per run rather than once per file, and can also be run later from Disk Operations.
• Shredding a folder is dramatically faster. VaultSort was re-examining the drive for every single file it walked, at roughly half a second each — a thousand-file folder spent about seven minutes learning the same fact about the same drive over and over. It now asks once per volume: about half a second in total, whatever the folder holds.

Bug Fixes

• Any program on your Mac could ask VaultSort's privileged helper to erase a disk or securely delete files. The helper accepted any process that knew the name of its service and had a valid process id, leaving its security entirely to the system's launch rules. It now verifies that whatever is calling it is genuinely signed as VaultSort, and refuses everything else.
• A shredded document could leave part of itself behind, unwritten over. Before overwriting a file, VaultSort disguises its size — and for most documents that means shrinking it, which handed those blocks back to the drive with the original contents still in them, before anything had been written over them. The overwrite that followed covered only what was left. On a 2 MB PDF that was roughly a megabyte of the original document, recoverable with any undelete tool. The tail is now overwritten while it still belongs to the file, which is the only moment writing to it means anything.
• VaultSort said free space had been cleared when it had not. On APFS — which is every Mac sold for years — the free-space step VaultSort ran is refused outright by macOS in a fraction of a second, and the refusal was being swallowed: you saw "Overwriting free space", then a success. On an external drive the engine went further and told you the overwrite had been sufficient, which on APFS is knowably false. And shredding a folder said nothing at all where shredding a single file inside it would have warned you. Every one of those now reports what actually happened, after the fact rather than as an intention beforehand, and a folder says it once for the volume instead of promising a duration it cannot keep.
• The wrong shred method was being chosen for your drive, in four separate ways. On macOS, the check for whether a drive is flash or magnetic examined the boot disk no matter which drive you asked about, and then read its answer wrongly — so it said flash, always. An encrypted drive's label matched none of the rules, so the refusal that withholds a free-space fill from flash never fired on one. A free-space overwrite was withheld from any APFS drive for a reason that was actually an argument in favour of it. And when a drive could not identify itself, the app told you to set its type by hand under Advanced Drive Information, honoured your answer when deciding what to offer — and then had no way to tell the engine, which refused the operation the app had just offered. Your override now reaches the engine, and only your override does: VaultSort never passes off its own guess as your answer.
• A failed decrypt could make the next attempt blame your disk. When a decrypt failed part way — a folder of that name already exists, most often — the hidden staging area it had been unpacking into was left behind holding the archive. The retry reused it, ran out of room inside it, and reported "no space left on device" to someone with 7 GB free. Staging is now released when an operation ends, and because several operations can legitimately run at once, it is only torn down when the last one using it has finished — before this, an encrypt finishing could pull the ground out from under a decrypt still writing. A genuine out-of-space failure now keeps the measured wording where there is one ("it needs about X MB free but only Y is available") and no longer replaces the other reasons in a mixed batch.
• A late failure could delete a file that had already been written successfully. Both the encrypt and decrypt paths could run their cleanup after you had been told the file was finished, removing it. On Windows, the same class of bug made adding a backup key or re-keying a file fail with "Replace failed… attempting backup restore", because VaultSort tried to move the file while it was still holding the file open itself. Both sides now wait for the file to be genuinely closed, and a cleanup that arrives after success no longer runs.
• Decrypting a mixed selection with a recovery code could quietly drop files. Three faults, all in the same flow: VaultSort asked only the first file in your selection whether it had a recovery slot and applied that answer to everything, so a folder encrypted across the day you set up your code either never offered the dialog at all or offered it for files it could not open; choosing the code for one group of files discarded that group and ran another key prompt underneath the dialog you were already typing into, so you typed your code once and only the last group came out; and a selection that opened partly by key and partly by code ended up showing only half of what it had produced. The files were never lost from disk, but nothing said what had happened.
• "YubiKey decryption failed" no longer appears while VaultSort is waiting for your recovery code. When every file needed the code, the run reported a failure the instant the dialog opened — so you watched a decrypt fail and then succeed. Separately, a batch of secure deletes raised one notification per file plus a summary, with the reason in one and the consequence in the other; each batch now reports once, carrying both.
• Key Sync stopped telling you files were fine when your recovery code could not open them. They counted as fully synced and showed the green chip, on the one screen where you would otherwise have discovered that your code opens some of your files and not the rest. The green chip now reads "Keys in sync", which is all it ever counted, and the files your code cannot open are listed beside it.
• Settings and the security-key notice no longer imply things about your protection that are not true. Settings sold a recovery code in general terms with no hint that it only covers files encrypted after you add it — including on the screen shown to someone who already has one and is checking. The security-key notice was still written for the old encryption format: it claimed any registered key can decrypt any file, that new files are automatically encrypted with all your keys, and that removing a key makes files permanently inaccessible. None of those are true now, and each was wrong in the direction that loses files.
• A duplicate scan on Windows no longer downloads your entire cloud library. Folders backed by OneDrive Files On-Demand are mostly placeholders, and VaultSort opened every one of them to hash it — pulling the whole lot down over your connection, possibly against a metered quota, and leaving it all pinned locally, while the scan looked merely slow. Placeholders are now skipped and counted, exactly as iCloud's already were, and the tile reporting it no longer tells a OneDrive user that iCloud omitted their files.
• Automatic updates no longer give up for six hours after one failed attempt. The launch check runs a few seconds after the window appears, which on a cold start is often before the network is ready, so it failed with a name-resolution error and then waited — and the release sat undownloaded until someone opened the Updates screen by hand. A failed automatic attempt now retries after 30 seconds, 2 minutes, 10 minutes and 30 minutes before falling back to the six-hourly schedule.
• When something cannot be deleted, VaultSort now says why. Space Saver told you to "check the logs for details" while holding the reason, and could show you the bare word declined after you had simply clicked Cancel on the permission prompt. Ten distinct causes are now named and grouped by cause with a count, rather than twenty near-identical lines, and the ones that are not really failures — the item was already gone, you cancelled — say so. A per-file secure delete that failed in Secure also discarded its reason before showing the notification; it now carries it.
• Checking a folder's size or repairing the helper could freeze VaultSort for 30 seconds. Two paths in the privileged helper did their repair work while holding the queue that repair work needs, which is a permanent deadlock ended only by a timeout. Both now do that work off the queue.
• VaultSort stopped telling you to approve a helper you had already approved. A rebuilt or re-signed helper reports as awaiting approval while System Settings still shows an enabled VaultSort entry from the previous registration — so the app insisted the toggle was off while you were looking at it switched on, and following the instruction again changed nothing. Four different underlying states shared one sentence; they are now named separately, including this one.
• A refused disk erase leaves your drive usable. Every refusal on that path happens before anything is written, but the drive's volumes were left unmounted with nothing to bring them back, so the natural next step was to unplug it. Whatever VaultSort unmounted, it now remounts. The refusal itself also says which thing changed and gives both values, instead of one sentence covering five different situations — two of which were not changes at all, but gaps in what VaultSort had recorded, and blamed the drive for them.
• Clicking the Dock icon after closing the last window works again. VaultSort kept a reference to the closed window that looked valid and threw on every use, so activating from the Dock raised an error instead of rebuilding the window. A Finder action arriving after a close hit the same fault; it is now held for the next window rather than dropped.
• Organize results show their file counts again. Every row of every batch was missing its expander and its "N files • X MB", because the app was looking for a format the engine stopped printing. A folder that vanished mid-run no longer reads as an organize that measured zero files, either — it says it never ran.