v2.2.1

Bug fix release addressing two classes of file-collision in clonarr's local storage that could cause silent data loss. Investigation prompted by btTeddy's detailed report on the TRaSH Guides Discord — thanks for taking the time to write it up.

What's fixed (verified)

• Same-name profiles on Radarr and Sonarr no longer overwrite each other at write time. Before this release, profiles in /config/profiles/ used filenames derived only from the sanitized name. If you imported the same TRaSH profile to both apps (Advanced → Import Profile), or built a custom profile with the same name on both via Profile Builder, saving the second wrote over the first. Filenames now include an app-type suffix (-radarr / -sonarr). Credit @ColeSpringer via #28.
• Migration of existing profile filenames is now wired at startup (profilesStore.MigrateFilenames()). PR #28's wire-up was missed for the profile store; without this call, existing on-disk files kept their pre-fix names and the new format only kicked in on next save.
• Migration-time collision protection. When two existing files would migrate to the same target filename (e.g. names HD and HD ! both sanitize to hd-sonarr.json), the alphabetically-first source wins; the rest stay at their original filenames with a log warning. Without this guard, the second os.WriteFile silently overwrote the first during upgrade. Covers all FileStore-backed data — profiles, custom CFs, and cf-groups.

Honest scope statement

The investigation was triggered by btTeddy's report of a Radarr profile "almost reset to stock" with personal CFs gone, alongside hex-named ghost CFs in his Sonarr profile and truncated sync history. We've shipped fixes for two specific filename-collision classes that could plausibly cause part of his symptoms, but we cannot confirm those fixes fully explain his exact bug. Possibilities still on the table:

• His report could be the cross-Arr profile collision we did fix (if he had imported/built the profile rather than only using TRaSH Sync).
• Or it could be a separate within-appType collision in the custom-CF migration from v2.0.4.
• The migration-time collision protection now ships for the custom-CF and cf-group stores too, so the second class is protected for the future.

If you upgrade and continue to see profile-reset, history-truncation, or hex-named ghost CFs symptoms, please file a GitHub issue — we want to keep tracing.

Recovery for already-affected installs

These fixes prevent future loss but do not recover data already overwritten on disk. Re-import or rebuild affected profiles and re-add personal CFs + score overrides, OR restore from a host-level backup of /config/profiles/ and /config/custom/json/ from before v2.0.4.

Still under investigation

• Hex-named "ghost" CF references — orphan-cleanup landing in a follow-up.
• Sync history truncation — root cause not confirmed; please file an issue if you see this.

---

Full changelog