mirror of
https://github.com/willmiao/ComfyUI-Lora-Manager.git
synced 2026-09-20 18:51:26 -03:00
Will Miao
c55c6f0a41
A scan that finds no recipe files at all is not a reliable deletion signal: an unmounted drive, a recipes_path that silently falls back to another LoRA root, or a cache shared with a second instance all look exactly like a real wipe. The reconcile step treated them all as deletions and overwrote the persistent cache with an empty one, so DELETE FROM recipes destroyed the user's only record of their recipes and the FTS index was rebuilt from the empty view (#1116). Guard the prune: - _reconcile_recipe_cache reports an all-missing result when every persisted recipe file is gone AND the stored rows match the recorded file stats. An internally inconsistent cache (leftover orphans) is stale, not evidence of a fresh disappearance, and still prunes. - The caller keeps the stored cache and logs a warning naming the directory it scanned and the number of recipes it preserved, instead of writing the empty result. It also skips the FTS rebuild so the index stays aligned with the stored rows. - save_cache gains skip_if_empty as a storage-level backstop: refuse to empty a populated cache. Intentional clears (manual rebuild) keep the default behaviour. - Log the resolved scan directory per run so a support reader can tell a real wipe apart from a scan that looked elsewhere. Partial orphans (ordinary manual deletions) keep pruning as before.