fix: handle non-existent file paths in tab management

[Kakueeen]

1. Added Utils::getFilePath() that returns canonicalFilePath() for
   existing files and falls back to absoluteFilePath() for non-existent
   files to support new file creation.
2. Updated StartManager to use Utils::getFilePath() instead of directly
   using canonicalFilePath() when opening files in windows/tabs.
3. Modified EditWrapper::handleFileLoadFinished to suppress error
   notifications for non-existent files (new file scenario).
4. Fixed issue where tabs for new files could not be properly displayed
   or closed due to empty canonical paths.

Log: When creating new files, the editor no longer shows spurious error
popups or fails to manage tabs correctly.

Influence:

1. Test creating new files from various entry points (e.g., double-click
   in file manager, command line, DBus).
2. Verify that existing files still open correctly with symlinks
   resolved.
3. Verify that tabs for new files display correctly and can be closed
   without errors.
4. Verify that opening non-existent files via recent files list does not
   cause error dialogs.

fix: 处理标签页管理中不存在的文件路径

1. 新增 Utils::getFilePath() 方法，对已存在文件返回规范路径，对不存在的
   文件返回绝对路径，以支持新建文件场景。
2. 更新 StartManager 中使用 Utils::getFilePath() 替代直接使用
   canonicalFilePath() 打开文件。
3. 修改 EditWrapper::handleFileLoadFinished，对于不存在的文件静默处理
   （新建文件场景），不显示错误提示。
4. 修复新建文件时标签页无法正确显示或关闭的问题。

Log: 新建文件时，编辑器不再显示错误弹窗，标签页管理恢复正常。

Influence:

1. 测试从不同入口新建文件（如双击文件管理器、命令行、DBus接口）。
2. 验证已存在文件仍能正确打开，且符号链接解析正常。
3. 验证新建文件的标签页显示正确且可以正常关闭。
4. 验证从最近文件列表打开不存在的文件时不会弹出错误对话框。

BUG: https://pms.uniontech.com/bug-view-336931.html

[sourcery-ai]

Sorry @Kakueeen, 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，很高兴为你审查这段代码。

这次代码变更的核心目的是解决新建文件（不存在的文件）在使用 QFileInfo::canonicalFilePath() 时返回空字符串，导致文件路径解析失败、标签页无法正常显示和关闭的问题。通过引入 Utils::getFilePath() 方法，采用 canonicalFilePath() 优先，absoluteFilePath() 兜底的策略，同时静默处理了新建文件的读取错误提示。

整体逻辑清晰，改进合理。但为了代码的健壮性、安全性和可维护性，我为你提供以下详细的审查意见：

1. 语法与逻辑

• 潜在问题：符号链接解析不一致
  • 分析：当文件不存在时，Utils::getFilePath() 返回 absoluteFilePath()，这个路径不会解析符号链接。当用户在这个路径下创建了文件后，程序再次获取路径时，canonicalFilePath() 将返回解析后的真实路径。这会导致同一个文件在创建前后拥有两个不同的路径字符串，可能会引起后续的标签页去重（getFileTabInfo）或路径匹配逻辑失效。
  • 建议：如果业务逻辑强依赖路径的唯一性来标识文件，建议在文件保存或创建成功后，主动刷新标签页或内部记录的文件路径，确保使用 canonicalFilePath()。或者在 getFilePath 的注释中明确说明此行为，提醒调用方注意路径状态可能发生变迁。

2. 代码质量

• 建议：减少重复的 QFileInfo 对象构造
  • 分析：在 src/startmanager.cpp 中，代码先调用了 Utils::getFilePath(file)（内部构造了一次 QFileInfo），随后可能又将其传入其他函数（如 checkPath、addTab 等），这些函数内部可能再次构造 QFileInfo。
  • 建议：如果性能敏感，可以考虑让 Utils::getFilePath 接受 QFileInfo 作为参数，或者在 startmanager.cpp 中直接构造一次 QFileInfo 并传递。不过考虑到文件操作 I/O 本身的耗时，这里的 CPU 开销微乎其微，保持当前写法也可，仅作优化参考。
• 建议：统一日志中的命名规范
  • 分析：在 startmanager.cpp 中，将变量名从 canonicalFile 改为了 resolvedFile，这是一个很好的改进，因为名称更符合其实际行为。但日志中的描述 "File already open, skipping:" 似乎与 checkPath 的逻辑反了（通常 checkPath 返回 true 代表通过/不存在，返回 false 代表已存在，这里 !checkPath 为 true 时打印 "already open"，需确认逻辑是否完全正确）。
• 细节：空白符变更
  • 分析：utils.cpp 和 editwrapper.cpp 中存在多处仅移除行尾空格的修改（如 - 紧接 + 但内容相同）。这无伤大雅，但建议在提交时将格式化修改与逻辑修改分离，保持 Git 历史清晰。

3. 代码性能

• 性能隐患：QFileInfo::canonicalFilePath() 的系统调用开销
  • 分析：canonicalFilePath() 底层会调用操作系统的 stat 等系统调用去解析符号链接并验证文件是否存在。在 openFilesInWindow 和 openFilesInTab 的循环中，如果用户一次性拖入大量文件，会引发密集的磁盘 I/O 和系统调用。
  • 建议：对于批量打开文件的场景，当前的开销通常是可接受的。但如果未来需要支持超大批量文件打开，可以考虑在 Utils 中增加路径缓存机制，或者在批量处理时异步解析路径。

4. 代码安全

• 安全隐患：路径遍历攻击 风险
  • 分析：absoluteFilePath() 会将相对路径转为绝对路径，但它不会校验路径中是否包含恶意的 ../。例如，如果传入 ../../../etc/passwd 且文件不存在，getFilePath 会原样返回这个包含 ../ 的绝对路径。如果后续的 addTab 或底层文件读写逻辑没有对路径进行规范化校验，可能会存在路径遍历的安全风险。而 canonicalFilePath() 在文件存在时会消除 ../，但文件不存在时它返回空，把这个安全兜底的责任推给了后续逻辑。
  • 建议：在 Utils::getFilePath() 中，即使文件不存在，也应该先对路径进行清理。可以使用 QDir::cleanPath(info.absoluteFilePath()) 来消除 ../ 等冗余符号，确保返回的路径是干净的。

改进后的代码建议

针对上述安全性和逻辑问题，建议对 Utils::getFilePath() 进行如下增强：

QString Utils::getFilePath(const QString &filePath)
{
    QFileInfo info(filePath);
    QString canonicalPath = info.canonicalFilePath();
    
    // canonicalFilePath() returns empty string for non-existent files
    // Use absoluteFilePath() as fallback to support creating new files
    if (canonicalPath.isEmpty()) {
        // 使用 QDir::cleanPath 清理路径中可能存在的 "." 或 ".."，防止路径遍历风险
        // 并确保即使是不存在的文件，返回的也是格式规范的绝对路径
        return QDir::cleanPath(info.absoluteFilePath());
    }
    
    return canonicalPath;
}

同时，建议完善 utils.h 中的注释，明确路径变迁的风险：

    /**
     * @brief getFilePath 获取文件路径
     * @param filePath 原始文件路径
     * @return 文件路径
     * @note 优先使用 canonicalFilePath()（解析符号链接并消除 '.' 或 '..'），
     *       当文件不存在时返回空字符串，此时使用 QDir::cleanPath(absoluteFilePath()) 
     *       作为后备方案，确保即使是新建文件，标签页也能正确显示和关闭。
     *       【注意】对于不存在的文件，此方法无法解析符号链接。当该文件后续被创建时，
     *       调用方需注意更新路径，以免同一文件因路径形态不同而导致标签页重复。
     */
    static QString getFilePath(const QString &filePath);

总结

本次代码修改方向正确，有效地修复了新建文件场景下的路径获取和错误提示问题。主要改进点在于防范路径遍历风险（使用 QDir::cleanPath）以及在文档中明确路径状态变迁的潜在影响。采纳上述建议后，代码将更加健壮安全。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Kakueeen, 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

[Kakueeen]

/forcemerge

[deepin-bot]

This pr force merged! (status: unstable)