fix: [unrar] can not extract rar files with longFilenames#366
fix: [unrar] can not extract rar files with longFilenames#366deepin-bot[bot] merged 1 commit intolinuxdeepin:release/eaglefrom
Conversation
Reviewer's GuideAdds capability checks for an external moveProgram before enabling long-filename handling during extraction, and disables that handling with warnings when the required tool (e.g., unrar’s helper) is unavailable to avoid failed extractions for RAR files with long filenames. Flow diagram for long filename handling with moveProgram capability checkflowchart TD
A[bHandleLongName is true?] -->|no| Z[Proceed without long filename handling]
A -->|yes| B[Read moveProgram from m_cliProps]
B --> C{Is moveProgram empty?}
C -->|yes| D[Set hasMoveCapability to false]
C -->|no| E[Find executable path with QStandardPaths::findExecutable]
E --> F{Executable path found?}
F -->|yes| G[Set hasMoveCapability to true]
F -->|no| D
D --> H{hasMoveCapability is true?}
G --> H
H -->|yes| I[Keep bHandleLongName true and call handleLongNameExtract]
H -->|no| J[Log warnings about missing moveProgram and archive format]
J --> K[Set bHandleLongName to false]
K --> Z
I --> L[If handleLongNameExtract fails set m_eErrorType to ET_FileWriteError]
L --> Z
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- The
hasMoveCapability/moveProgramlookup and associatedqWarningblock is duplicated in two places; consider factoring this into a small helper or a single early check to avoid repetition and keep the long-name handling logic in one place. - Since
QStandardPaths::findExecutable(moveProgram)is relatively expensive and does not change during a single extraction, you could compute the move capability once and reuse it instead of calling it multiple times.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `hasMoveCapability`/`moveProgram` lookup and associated `qWarning` block is duplicated in two places; consider factoring this into a small helper or a single early check to avoid repetition and keep the long-name handling logic in one place.
- Since `QStandardPaths::findExecutable(moveProgram)` is relatively expensive and does not change during a single extraction, you could compute the move capability once and reuse it instead of calling it multiple times.
## Individual Comments
### Comment 1
<location path="3rdparty/interface/archiveinterface/cliinterface.cpp" line_range="199-212" />
<code_context>
}
}
+
+ // 检查是否有可用的 moveProgram 来处理长文件名 (unrar无法修改rar压缩包内文件名)
+ bool hasMoveCapability = false;
+ QString moveProgram = m_cliProps->property("moveProgram").toString();
+ if (!moveProgram.isEmpty()) {
+ QString moveProgramPath = QStandardPaths::findExecutable(moveProgram);
+ hasMoveCapability = !moveProgramPath.isEmpty();
+ }
+
+ if (bHandleLongName && !hasMoveCapability) {
+ qWarning() << "Long filename detected, but moveProgram (" << moveProgram << ") is not available.";
+ qWarning() << "Archive format:" << m_mimetype.name() << "Skipping long name handling.";
+ qWarning() << "The extraction tool will report errors for files with names exceeding system limit (255 bytes).";
+ bHandleLongName = false;
+ }
+
</code_context>
<issue_to_address>
**suggestion:** Avoid duplicated moveProgram capability check and warning logic.
The `moveProgram` lookup and `hasMoveCapability` handling (warnings and `bHandleLongName` reset) now appear in two places in this function, duplicating work and log messages and obscuring control flow. It would be clearer to perform this capability check only once—ideally after `bHandleLongName` is finalized (post `bLnfs`/NAME_MAX scan)—or encapsulate it in a small helper such as `bool ensureMoveCapabilityOrDisableLongName()` to avoid repetition and make the conditions for disabling `bHandleLongName` explicit.
```suggestion
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
prevent extracting RAR files with long filenames when unrar tool is missing Log: as title Bug: https://pms.uniontech.com/bug-view-343139.html
ff8c1b9 to
849c3d3
Compare
deepin pr auto review以下是对提供的 1. 语法与逻辑
2. 代码质量
3. 代码性能
4. 代码安全
5. 具体修改建议针对上述分析,建议对 PluginFinishType CliInterface::extractFiles(const QList<FileEntry> &files, const Options &options)
{
// ... 前面的代码 ...
// 1. 确定初始的 bHandleLongName 状态
bool bHandleLongName = /* ... 原有逻辑 ... */;
// 2. 统一检查处理长文件名的能力 (消除重复)
if (bHandleLongName) {
if (!checkMoveCapability()) {
qWarning() << "Long filename detected, but moveProgram ("
<< m_cliProps->property("moveProgram").toString()
<< ") is not available.";
qWarning() << "Archive format:" << m_mimetype.name() << "Skipping long name handling.";
// 可以在这里进一步检查是否真的有超长文件名,如果有则直接返回错误
bHandleLongName = false;
}
}
// 3. 后续逻辑使用确定后的 bHandleLongName
if (destPath.startsWith("/tmp") && destPath.contains("/deepin-compressor-")) {
// ...
}
// ...
if (!bLnfs) {
// ...
}
// 这里不再需要重复 checkMoveCapability 的代码块
if (bHandleLongName) {
if (!handleLongNameExtract(arcData.mapFileEntry.values())) {
// ...
}
}
// ...
}总结这段代码的主要问题在于逻辑重复,这不仅影响代码的整洁性,也带来了微小的性能损耗。通过合并检查逻辑,可以显著提升代码质量。此外,新增的 |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: LiHua000, max-lvs The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
/merge |
prevent extracting RAR files with long filenames when unrar tool is missing
Log: as title
Bug: https://pms.uniontech.com/bug-view-343139.html
Summary by Sourcery
Bug Fixes: