Resolved / August 14, 2026
FVS Storage startup regression resolved
cpak v2.2.0 fixes the slow application startup reported with v2.1.x. Existing applications and user data remain in place, and any required storage migration is handled automatically after the update.
The regression delayed applications before their windows appeared. The first launch was usually the slowest, while later launches could be much faster. This made the problem seem inconsistent even though the delay was inside cpak and affected unrelated applications.
No application data was damaged. The delay came from filesystem preparation that had been placed in the launch path when FVS Storage became the default in v2.1.0.
Application startup is direct again
cpak v2.2.0 prepares each immutable layer once and reuses the result. Applications can then start directly through rootless OverlayFS without waiting for a new FUSE view on every launch. FVS still provides content-level deduplication and verified storage, but its maintenance work no longer sits between a click and the application process.
Warm launches return to the normal direct path, including links that open an application already running. Storage checks run only when there is actual work to complete.
Existing installations update in place
Users on cpak v2.1.x can update directly to v2.2.0. Applications do not need to be reinstalled, and their settings and files are not moved. If an existing store needs an update, cpak shows its progress once and resumes safely if the operation is interrupted.
The temporary v2.0.1 fallback is no longer needed. Anyone who stayed on that version can also update directly to v2.2.0.
If an application is still slow
A launch that remains slow after the migration may have a different cause. Reports should include the cpak version, package name, filesystem and separate timings for the first and second launch. That is enough to distinguish storage preparation from application startup.
