fix: Fix ZIP multi-volume compression not working after pzip plugin w…

[dengzhongyuan365-dev]

…as introduced

• pzip plugin (priority 200) preempted cli7z (priority 180) for all ZIP compression tasks, but pzip does not support multi-volume splitting.
• Added explicit plugin selection to force cli7z when ZIP multi-volume is requested, restoring the original behavior.

bug: https://pms.uniontech.com/bug-view-360941.html

[sourcery-ai]

Sorry @dengzhongyuan365-dev, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[deepin-ci-robot]

deepin pr auto review

你好！我是CodeGeeX，你的智能编程助手。我已仔细审查了你提供的 Git Diff 内容。本次修改主要涉及 .gitignore 文件的更新以及 mainwindow.cpp 中压缩逻辑的分支调整。

以下是我从语法逻辑、代码质量、代码性能和代码安全四个维度提出的详细审查意见与改进建议：

1. 语法与逻辑

• 逻辑分支覆盖与潜在冲突：
  新增的分支 else if (options.bSplit && "application/zip" == m_stCompressParameter.strMimeType) 逻辑上是清晰的，即“当分卷压缩且格式为 ZIP 时，使用 7z 命令行工具”。
  潜在风险：原代码中有一个分支 if ((false == options.bSplit) && true == bUseLibarchive && "application/zip" == ...)，专门处理“非分卷的 ZIP 使用 libarchive”。现在加入了分卷 ZIP 使用 CLI7z 的逻辑。需要确认：如果 bUseLibarchive 为 false 且非分卷时，原代码是如何处理的？新增分支没有检查 bUseLibarchive，这在逻辑上是合理的（因为分卷统一走 7z），但需确保这符合整体架构设计。
• 隐式依赖：
  新增逻辑隐含了一个前提：UiTools::APT_Cli7z 必须支持 ZIP 格式的分卷压缩。虽然 7z 命令行工具确实具备此能力，但需确认你们的 APT_Cli7z 封装层是否已经实现了对 ZIP 格式分卷的完整参数传递。

2. 代码质量

• 条件判断风格不一致：
  在同一个 if-else 链中，存在不同的布尔值判断风格：
  • 旧代码：false == options.bSplit 和 true == bUseLibarchive（Yoda 条件/显式比较）
  • 新代码：直接使用 options.bSplit（隐式布尔转换）
    建议在同一代码块内保持风格统一。C++ 中直接使用 if (options.bSplit) 和 if (!bUseLibarchive) 是更符合现代 C++ 规范的写法，可读性更强。
• 硬编码的魔法字符串：
  "application/zip" 和 "application/x-compressed-tar" 等字符串在代码中多次硬编码。建议将其提取为常量或枚举，避免因拼写错误导致逻辑失效，同时提高可维护性。

3. 代码性能

• 分卷压缩的性能损耗：
  注释中提到，之前针对华为 ARM 平台的 ZIP 压缩特意使用了 libarchive 以提升性能。现在将分卷 ZIP 转移到了 APT_Cli7z。
  性能疑问：7z 在处理 ZIP 格式分卷时，通常需要先将所有数据压缩成单个 ZIP 文件，然后再进行分卷切割（或者通过管道流式处理，取决于具体实现）。如果你们的 APT_Cli7z 是前者，在处理超大文件时，会导致双倍的磁盘 I/O 和临时空间占用，且耗时可能显著增加。建议对大文件（如 GB 级别）的分卷 ZIP 压缩进行专项性能测试。

4. 代码安全

• 命令注入风险（针对 CLI7z）：
  由于新增逻辑将分卷 ZIP 交由 APT_Cli7z（命令行工具）处理，必须极度关注命令注入风险。如果 m_stCompressParameter.strArchiveName 或文件列表来源于用户输入，且在拼接 7z 命令行字符串时未经过严格转义，攻击者可以通过构造文件名（如 ; rm -rf / #.zip）来执行任意命令。
  安全建议：请检查 APT_Cli7z 的底层实现，确保使用的是安全的执行方式（如 QProcess 的参数列表传递，而不是字符串拼接），并对文件路径进行了严格的合法性校验和转义。
• 临时文件安全：
  如性能部分所述，如果 7z 分卷需要生成临时文件，请确保临时文件创建在安全的目录中，且具有合理的权限（如仅当前用户可读写），防止敏感数据泄露。

---

改进建议代码示例

针对 mainwindow.cpp，建议进行如下重构以提升代码质量和安全性：

// 建议在头文件或匿名命名空间中定义常量，避免魔法字符串
namespace {
    constexpr const char* MIME_TYPE_ZIP = "application/zip";
    constexpr const char* MIME_TYPE_TAR_GZ = "application/x-compressed-tar";
}

// ... 函数内部 ...
void MainWindow::slotCompress(const QVariant &val)
{
    // ... 前置逻辑 ...

    // 统一布尔值判断风格，去除冗余的 true/false 比较
    } else if (!options.bSplit && bUseLibarchive && MIME_TYPE_ZIP == m_stCompressParameter.strMimeType) {
        // 考虑到华为arm平台 zip压缩 性能提升，只针对zip类型的压缩才会考虑到是否特殊处理arm平台，分卷情况不做此处理
        eType = UiTools::APT_Libarchive;
    } else if (options.bSplit && MIME_TYPE_ZIP == m_stCompressParameter.strMimeType) {
        // 【注意】此处依赖 APT_Cli7z，需确保底层 QProcess 防命令注入，且评估大文件分卷时的临时空间与性能消耗
        eType = UiTools::APT_Cli7z;
    } else if (MIME_TYPE_TAR_GZ == m_stCompressParameter.strMimeType && m_stCompressParameter.strArchiveName.endsWith("tar.gz")) {
        if (1 == m_stCompressParameter.iCPUTheadNum) {
            // 针对单线程的tar.gz，使用gzip默认方式进行压缩
        }
    }
    
    // ... 后续逻辑 ...
}

关于 .gitignore 的审查

新增的 .claude/, .npm-cache/, .trellis/ 属于本地开发工具或包管理器的缓存目录，加入 .gitignore 是完全正确的，不会对项目逻辑产生任何不良影响。

希望这些审查意见对你有所帮助！如果有关于 APT_Cli7z 实现细节的代码，也可以提供给我，我可以进一步为你排查命令注入等安全隐患。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: dengzhongyuan365-dev, lzwind

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[dengzhongyuan365-dev]

/merge