fix: 修复 #35 #36 #38 - #39
Conversation
|
@codex 审查提交 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 238220524d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if self._sha256(target_path) != entry.get("replacement_sha256"): | ||
| skipped_files.append({"target_rel": target_rel, "reason": "target_changed_externally"}) | ||
| remaining_entries.append(entry) | ||
| skipped_files.append({"target_rel": target_rel, "reason": "target_changed_externally", "record_cleared": True}) | ||
| continue |
There was a problem hiding this comment.
When the tracked target hash differs because the user or another tool installed a third-party sound file, this branch now drops the entry from active_entries instead of keeping it. After restore() returns this skipped result, get_status() reports the game as clean and the original backup is no longer reachable through the normal restore flow, leaving the external file installed. Only clear the record when the current hash is known to be the original (for example it matches original_sha256); otherwise keep the entry so the user can still recover or retry.
Useful? React with 👍 / 👎.
| lock_path = lock_path or (Path(tempfile.gettempdir()) / "AimerWT.single-instance.lock") | ||
| try: | ||
| lock_file = open(lock_path, "a+b") |
There was a problem hiding this comment.
On Unix systems where tempfile.gettempdir() is a shared /tmp, this creates a persistent lock file owned with the first user's umask permissions. Once one user has run the app, another user can hit PermissionError on open(..., "a+b") even after the lock is released, and the except OSError path treats that stale permission failure as “already running,” blocking launch. Put the lock in a per-user runtime/config directory or create it with permissions that do not make other users' stale files look like an active instance.
Useful? React with 👍 / 👎.
|
@codex 审查最新提交 |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: faa19322af
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| record_cleared = bool(original_sha and current_sha == original_sha) | ||
| skipped_files.append({ | ||
| "target_rel": target_rel, | ||
| "reason": "target_changed_externally", | ||
| "record_cleared": record_cleared, |
There was a problem hiding this comment.
When a user has already verified/restored the game file outside AimerWT, this new record_cleared path removes the active manifest entry but only records it as a skipped file, leaving restored_entries empty; restore() therefore returns success: False later even though the stale record was successfully cleared. AppApi.restore_game only clears current_mod and fires the success path when sound_result.success is true, so the UI can report “Sound restore incomplete” and keep the installed-mod marker stale after all active entries have been cleared.
Useful? React with 👍 / 👎.
1 participant
No description provided.