Repository navigation
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
嗨——我发现了 6 个问题
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="src-tauri/src/commands/utils.rs" line_range="246" />
<code_context>
+ .join(".local")
+ .join("share"),
+ };
+ Ok(base.join(project_name))
+}
+
</code_context>
<issue_to_address>
**Config saves are denied**
When linux is built with `xdg-data-dir` and the frontend attempts to save configuration, `get_app_data_dir` returns an XDG path, but the Tauri frontend’s `saveConfig` writes through the filesystem plugin and the configured recursive write permission is for app data. The plugin rejects writes to this path, so users cannot save configuration when this feature is enabled.
Add filesystem read/write scope for the resolved XDG directory, or perform configuration reads and writes through Rust commands that are not subject to the frontend filesystem scope.
</issue_to_address>
### Comment 2
<location path="src-tauri/src/commands/utils.rs" line_range="246" />
<code_context>
+ .join(".local")
+ .join("share"),
+ };
+ Ok(base.join(project_name))
+}
+
</code_context>
<issue_to_address>
**Existing settings are left behind**
When an existing Linux installation with configuration under the executable directory is launched with `xdg-data-dir` enabled, `AppConfigState::load_config` looks only under the newly selected XDG directory, so it ignores an existing installation’s `config/` under the executable directory and loads defaults. Saving then creates a separate XDG copy; users see their settings disappear, and switching back to a non-feature build exposes the stale copy.
On first feature-enabled launch, migrate the existing configuration and other persistent state into the XDG directory, or load the old configuration as a fallback and document the resulting migration behavior.
</issue_to_address>
### Comment 3
<location path="src-tauri/src/commands/utils.rs" line_range="247" />
<code_context>
Ok(path)
}
- #[cfg(not(target_os = "macos"))]
</code_context>
<issue_to_address>
**Same-name projects share data**
When two distinct installations have the same `interface.json` name, `base.join(project_name)` resolves both projects to the same XDG directory, so their configs, logs, and caches overlap; saving settings in one project changes the data used by the other.
Use a stable unique project identifier for the XDG directory, or enforce and document uniqueness of `name` across projects.
</issue_to_address>
### Comment 4
<location path="src-tauri/src/commands/utils.rs" line_range="247" />
<code_context>
Ok(path)
}
- #[cfg(not(target_os = "macos"))]
</code_context>
<issue_to_address>
**Concurrent saves overwrite shared config**
When two instances of the same project, or concurrent save requests, write configuration at the same time, separate instances of the same project now resolve to the same XDG directory, and concurrent config saves use the same `.tmp` path without cross-process coordination. One save can overwrite or remove the other’s temporary file, or a stale full-config save can replace newer changes; callers then see a failed save or lost configuration updates.
Serialize writes across processes (for example with a per-config lock) and use unique temporary filenames; merge or reject stale config versions rather than silently replacing newer state.
</issue_to_address>
### Comment 5
<location path="src-tauri/src/commands/utils.rs" line_range="247" />
<code_context>
Ok(path)
}
- #[cfg(not(target_os = "macos"))]
</code_context>
<issue_to_address>
**Update backups survive cleanup**
When linux is built with `xdg-data-dir` and an update leaves backup files in `exe_dir/cache/old`, `move_to_old_folder` writes backups under `exe_dir/cache/old`, but startup cleanup checks the XDG cache directory, so the backups remain. When those directories are on different filesystems, the move also fails and leaves the package in the XDG cache.
Make `move_to_old_folder` and startup cleanup use the same backup directory.
</issue_to_address>
### Comment 6
<location path="src-tauri/src/commands/utils.rs" line_range="193" />
<code_context>
+ Err(e) if e.kind() == std::io::ErrorKind::NotFound => None,
+ Err(e) => return Err(format!("读取 interface.json 失败: {}", e)),
+ };
+ let xdg_data_home = std::env::var_os("XDG_DATA_HOME").map(PathBuf::from);
+ let home = std::env::var_os("HOME").map(PathBuf::from);
+ linux_data_dir(
</code_context>
<issue_to_address>
**Non-UTF-8 paths target wrong directory**
When `XDG_DATA_HOME` or the fallback `HOME` contains non-UTF-8 bytes, `get_data_dir` and `AppConfigState::load_config` convert the path to a lossy string, so later frontend and backend operations use a different path and configuration or other data operations fail or target the wrong directory.
Preserve the original path without lossy string conversion for filesystem operations.
</issue_to_address>Original comment in English
Hey - I've found 6 issues
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="src-tauri/src/commands/utils.rs" line_range="246" />
<code_context>
+ .join(".local")
+ .join("share"),
+ };
+ Ok(base.join(project_name))
+}
+
</code_context>
<issue_to_address>
**Config saves are denied**
When linux is built with `xdg-data-dir` and the frontend attempts to save configuration, `get_app_data_dir` returns an XDG path, but the Tauri frontend’s `saveConfig` writes through the filesystem plugin and the configured recursive write permission is for app data. The plugin rejects writes to this path, so users cannot save configuration when this feature is enabled.
Add filesystem read/write scope for the resolved XDG directory, or perform configuration reads and writes through Rust commands that are not subject to the frontend filesystem scope.
</issue_to_address>
### Comment 2
<location path="src-tauri/src/commands/utils.rs" line_range="246" />
<code_context>
+ .join(".local")
+ .join("share"),
+ };
+ Ok(base.join(project_name))
+}
+
</code_context>
<issue_to_address>
**Existing settings are left behind**
When an existing Linux installation with configuration under the executable directory is launched with `xdg-data-dir` enabled, `AppConfigState::load_config` looks only under the newly selected XDG directory, so it ignores an existing installation’s `config/` under the executable directory and loads defaults. Saving then creates a separate XDG copy; users see their settings disappear, and switching back to a non-feature build exposes the stale copy.
On first feature-enabled launch, migrate the existing configuration and other persistent state into the XDG directory, or load the old configuration as a fallback and document the resulting migration behavior.
</issue_to_address>
### Comment 3
<location path="src-tauri/src/commands/utils.rs" line_range="247" />
<code_context>
Ok(path)
}
- #[cfg(not(target_os = "macos"))]
</code_context>
<issue_to_address>
**Same-name projects share data**
When two distinct installations have the same `interface.json` name, `base.join(project_name)` resolves both projects to the same XDG directory, so their configs, logs, and caches overlap; saving settings in one project changes the data used by the other.
Use a stable unique project identifier for the XDG directory, or enforce and document uniqueness of `name` across projects.
</issue_to_address>
### Comment 4
<location path="src-tauri/src/commands/utils.rs" line_range="247" />
<code_context>
Ok(path)
}
- #[cfg(not(target_os = "macos"))]
</code_context>
<issue_to_address>
**Concurrent saves overwrite shared config**
When two instances of the same project, or concurrent save requests, write configuration at the same time, separate instances of the same project now resolve to the same XDG directory, and concurrent config saves use the same `.tmp` path without cross-process coordination. One save can overwrite or remove the other’s temporary file, or a stale full-config save can replace newer changes; callers then see a failed save or lost configuration updates.
Serialize writes across processes (for example with a per-config lock) and use unique temporary filenames; merge or reject stale config versions rather than silently replacing newer state.
</issue_to_address>
### Comment 5
<location path="src-tauri/src/commands/utils.rs" line_range="247" />
<code_context>
Ok(path)
}
- #[cfg(not(target_os = "macos"))]
</code_context>
<issue_to_address>
**Update backups survive cleanup**
When linux is built with `xdg-data-dir` and an update leaves backup files in `exe_dir/cache/old`, `move_to_old_folder` writes backups under `exe_dir/cache/old`, but startup cleanup checks the XDG cache directory, so the backups remain. When those directories are on different filesystems, the move also fails and leaves the package in the XDG cache.
Make `move_to_old_folder` and startup cleanup use the same backup directory.
</issue_to_address>
### Comment 6
<location path="src-tauri/src/commands/utils.rs" line_range="193" />
<code_context>
+ Err(e) if e.kind() == std::io::ErrorKind::NotFound => None,
+ Err(e) => return Err(format!("读取 interface.json 失败: {}", e)),
+ };
+ let xdg_data_home = std::env::var_os("XDG_DATA_HOME").map(PathBuf::from);
+ let home = std::env::var_os("HOME").map(PathBuf::from);
+ linux_data_dir(
</code_context>
<issue_to_address>
**Non-UTF-8 paths target wrong directory**
When `XDG_DATA_HOME` or the fallback `HOME` contains non-UTF-8 bytes, `get_data_dir` and `AppConfigState::load_config` convert the path to a lossy string, so later frontend and backend operations use a different path and configuration or other data operations fail or target the wrong directory.
Preserve the original path without lossy string conversion for filesystem operations.
</issue_to_address>There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0ab4ed363a
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| * @param dataPath 数据目录(macOS: ~/Library/Application | ||
| * Support/MXU/,其他平台: exe 目录) | ||
| * 使用应用数据目录(macOS: ~/Library/Application Support/MXU/, | ||
| * Linux 启用 xdg-data-dir feature: $XDG_DATA_HOME/{项目名},否则为 exe 目录)。 |
There was a problem hiding this comment.
Keep update archive cleanup on the XDG filesystem
When this feature is enabled and the XDG data home and executable reside on different mounts, update archives live in the XDG cache, but completion calls move_to_old_folder, which hard-codes <exe>/cache/old and uses std::fs::rename (src-tauri/src/commands/update.rs:156-199). The resulting EXDEV is swallowed by moveToOldFolder, and cleanup only removes .downloading files, so archives remain and versioned ones can accumulate; even on one filesystem, startup now cleans XDG cache/old rather than the executable's cache/old. Keep archival and cleanup on the data filesystem or handle copy-and-remove.
AGENTS.md reference: AGENTS.md:L45-L45
Useful? React with 👍 / 👎.
MistEO
left a comment
There was a problem hiding this comment.
基于最新提交 ff866b8,复核后确认两项问题,均涉及 Linux 启用 xdg-data-dir 后的更新流程:
-
[P2] 更新前配置备份仍读取 exe 目录 — updateService.ts:995
InstallConfirmModal将basePath作为安装目标targetDir传入,而installUpdate又将它传给backupConfigBeforeUpdate。启用 feature 后,实际配置位于 XDG 数据目录,但备份仍检查<exe>/config/mxu-{项目名}.json:全新 XDG 部署会静默跳过更新前备份;如果 exe 目录留有旧配置,还会备份错误版本。已用现有备份函数复现,并确认改传dataPath后能够读取当前配置并写入备份。建议为安装流程单独传入dataPath用于配置备份,安装目标仍使用basePath。 -
[P2] 更新归档与启动清理目录不一致,跨分区归档会失败 — update.rs:156–199、lib.rs:169–174
下载包现在位于 XDG 数据目录的
cache下,但move_to_old_folder仍把文件归档到<exe>/cache/old,启动时却只清理<dataPath>/cache/old。同一文件系统上,归档文件不会在下次启动时清理;当 XDG 数据目录与 exe 位于不同文件系统时,std::fs::rename返回EXDEV,该错误被上层忽略,下载包留在缓存中,带版本号的包可能逐次积累。已用现有移动函数复现这两种情况。建议分别协调下载包归档、安装目录旧文件备份与启动清理的路径,并为跨文件系统移动提供回退。
验证:启用 xdg-data-dir 的 Rust 42 项单元测试、前端 12 项测试及 TypeScript 检查全部通过;上述两项另做了针对性复现。
ff866b8 to
eb5bc45
Compare
|
配置备份与更新归档的目录归属问题是原本就存在的,这里选择全部改用数据目录 |
|
冲突了看看 |
Co-Authored-By: GPT-6.1 Sol <noreply@pi.dev> Generated-By: pi 0.87.1 (https://pi.dev)
Linux 数据目录改动以 `xdg-data-dir` feature 提供,默认构建仍保持 exe 目录的便携式布局,避免升级后配置/日志/缓存路径变更。 - Cargo.toml 声明 xdg-data-dir(非默认) - get_app_data_dir 按 all(target_os = "linux", feature = "xdg-data-dir") 分派 - linux_data_dir 及其 6 个单测随 feature 条件编译 - 文档见 docs/rust-features.md
更新前备份从 exe 目录读取配置,开启 xdg-data-dir 后会跳过备份或备份 错误版本;改为使用 dataPath。更新包归档也移到 dataPath/cache/old, 与下载目录同分区,避免跨文件系统 rename 失败后残留在缓存中。 启动清理同时处理 exe 与 data 的 cache/old;程序旧文件与回滚备份仍 保留在 exe 目录。 验证:cargo test --features xdg-data-dir(79 项)、cargo check、 tsc、Prettier 与前端 92 项测试通过。
eb5bc45 to
9e06ae6
Compare
|
已 rebase |
默认关,需要包管理器的自行开启构建即可
Sourcery 摘要
新增可选的 Linux XDG 数据目录模式,同时保留默认的便携式存储方式。
新功能:
xdg-data-dirCargo 功能,使用interface.json中的项目名称,将应用程序数据存储在 XDG 数据目录下。增强:
MXU和~/.local/share。构建:
xdg-data-dirCargo 功能,并提供启用该功能时的构建和测试指南。文档:
测试:
杂项:
Original summary in English
Sourcery 摘要
为 Linux 引入可选的 XDG 数据目录支持,同时保持默认构建使用便携式数据存储方式。
新功能:
xdg-data-dirCargo 功能,使应用数据可以按项目名称存储在 XDG 数据目录中,同时保留现有的便携式存储方式。错误修复:
改进:
构建:
xdg-data-dirCargo 功能及相应的构建和测试文档。文档:
测试:
杂项:
Original summary in English
Sourcery 摘要
新增可选的 Linux XDG 数据目录支持,同时保留默认的便携式存储行为。
新功能:
xdg-data-dirCargo 功能,可将应用数据存储在根据interface.json命名的 XDG 数据目录下,同时默认仍使用便携式的可执行文件目录存储方式。错误修复:
改进:
构建:
xdg-data-dirCargo 功能,并记录特定功能的构建和测试命令。文档:
测试:
杂项:
Original summary in English
Sourcery 摘要
在 Linux 上启用可选的、符合 XDG 规范的应用程序数据存储,同时仍默认使用便携式数据存储。
新功能:
xdg-data-dirCargo 功能,将应用程序数据存储在符合 XDG 规范且按项目区分的目录中,同时默认保留便携式存储方式。错误修复:
改进:
MXU和~/.local/share。构建:
xdg-data-dirCargo 功能,并记录特定功能对应的构建和测试命令。文档:
测试:
杂项:
Original summary in English
Summary by Sourcery
Enable optional XDG-compliant application data storage on Linux while retaining portable data storage as the default.
New Features:
xdg-data-dirCargo feature that stores application data under an XDG-compliant, project-specific directory while preserving portable storage by default.Bug Fixes:
Enhancements:
MXUand~/.local/sharewhere appropriate.Build:
xdg-data-dirCargo feature and document feature-specific build and test commands.Documentation:
Tests:
Chores: