File garbage collection is rebuilt. Files left behind when a user's home directory is removed keep occupying storage, and the old collector never found them. It now counts the directory entries that link to each file: a sweep moves files older than retention-period with no links to a trash collection, and a purge removes their keys, chunks and records once deleted-grace-period has passed. See Garbage Collector.
Multi-type API tokens. A Multi token carries any combination of the Team, VM, Project, Drive and User types and may call the routes for each, so one token can do work that needed five. This makes a system snapshot possible from a single credential. See the REST API reference.
Ten read-only routes cover realms, bricks, external servers, security requirements and levels, permissions, project memberships, project and team usage, user certifications, and managed objects, so inventory, reporting and compliance evidence can be collected with a credential that cannot change anything.
A capabilities route tells clients which features the backend supports, instead of leaving them to infer it from the version. The first flags are remove-directory-entries, multi-type API tokens and VM config drive keys.
Bulk directory entry deletion takes an immediate option that trashes newly unreferenced files straight away, so a user's quota reflects a large deletion without waiting for the next sweep.
A trashed file that a directory links to again is restored on the next purge pass, so a file that was marked and then relinked is never destroyed.
The file manager checks its chunk storage path at startup, and reports missing chunks during purges instead of counting them as deleted.
Bulk directory entry deletion returns the directory together with the caller's updated file usage, so a client no longer needs a second call to refresh a quota display.
The file garbage collector is disabled and in dry-run by default. enabled = true creates it, and dry-run = false lets it act.
Dry-run logs are written to /var/log/ticrypt/file-gc, configurable through log-directory, instead of /etc/ticrypt.
Bulk directory entry deletion writes its own audit row, BulkDirectoryEntryRemove (BDER), recording the parent directory, the entries removed, whether the parent itself was deleted, and the outcome.
Deleting a file removes its chunks from disk again. This had not happened since the storage service was removed, so deployments have chunk files on disk whose records are already gone, which the garbage collector cannot find. See Know what this does not reclaim.
Project usage aggregation no longer fails on MongoDB 3.6 and newer.
A race between restoring and purging the same trashed file is resolved.
Large file scans no longer stall after an idle connection between services.
Upgrade the package and restart the services: sudo dnf upgrade ticrypt-backend, then sudo ticrypt-services.sh restart.
Upgrading reclaims no storage and changes no collector behavior, because the collector ships disabled. To reclaim the storage, take it live by the procedure in Take the File Garbage Collector Live.
Before enabling the collector, check that ticrypt.filemanager.storage.path is correct and mounted. If it is not, chunk deletion fails silently and the storage is never reclaimed.
Run the collector with dry-run = true for several full frequency cycles, spot-check the file IDs in the candidate logs, and stop if any is a live file.
For the first live cycle, set dry-run = false with a wider deleted-grace-period, such as 14d, and watch the purge. Set enabled = false if anything looks wrong before the grace period ends.
The purge is permanent: it removes keys, chunks and records, with no undo and no backup taken first.
