mirror of
https://github.com/clash-verge-rev/clash-verge-rev.git
synced 2026-11-04 22:52:23 +08:00
Tunglies
8039feb270
* fix(backup): serialize restore with config write lock Acquire the configuration write lock at the entry of finalize_restored_verge_config so the clash, profiles and verge draft applies all happen under it, instead of only the verge layer. A concurrent patch (patch_clash / patch_verge via try_lock_config_write) could otherwise stage a draft that the unlocked restore applies overwrite, or interleave its persistence with the restore. Also drop the pointless clones in the clash and profiles edit_draft closures; edit_draft takes FnOnce so the restored values can be moved in. The lock is released before patch_verge, which re-acquires it via try_lock_config_write. * perf(backup): extract archive off the runtime Run File::open, ZipArchive::new and the extraction of the backup archive inside spawn_blocking. Extracting a multi-file backup blocked a tokio worker for hundreds of milliseconds to seconds while the runtime kept serving other work on the remaining workers. Move the PROFILE_WRITE_LOCK acquisition after the extraction, right before finalize_restored_verge_config: the lock protects the config-data transition (extracted files reloaded into drafts), not the plain filesystem writes, so profile operations no longer queue behind the blocking unzip. * fix(clash): take config write lock when changing mode change_clash_mode committed the clash draft and saved config.yaml without claiming CONFIG_WRITE_LOCK, so a concurrent patch_clash transaction could have its staged draft committed here or its file-snapshot rollback swallow the mode change. Take lock_config_write (waiting) rather than try_lock_config_write: two of the three callers (hotkey, tray) discard the result, so fail-fast would silently drop the switch, and the lock is only attempted after the mihomo patch already applied, where an Err would roll the frontend back while the core runs the new mode.