dde-file-manager 核心代码审查报告

三个函数各自创建了一份互不相干的局部 ok / errMsg：

// handleJobResult:108 —— 创建的 ok 从未被使用
QSharedPointer<bool> ok { new bool { true } };
QSharedPointer<QString> errMsg { new QString };
connect(ptr.get(), &AbstractJobHandler::errorNotify,  this, &FileOperationsEventHandler::handleErrorNotify);
connect(ptr.get(), &AbstractJobHandler::finishedNotify, this, &FileOperationsEventHandler::handleFinishedNotify);

// handleErrorNotify:121 —— 改写的是另一个局部对象，函数结束即丢弃
QSharedPointer<bool> ok { new bool { true } };
if (errType != AbstractJobHandler::JobErrorType::kNoError) {
    *ok = false;                          // ← 写入后立即销毁
    *errMsg = jobInfo->value(...).toString();
}

// handleFinishedNotify:143 —— 又新建一个 ok=true，永远为真
QSharedPointer<bool> ok { new bool { true } };
publishJobResultEvent(jobType, srcUrls, destUrls, customInfos, *ok, *errMsg);   // 恒为 true / ""
removeUrlsInClipboard(jobType, srcUrls, destUrls, *ok);                        // 恒为 true

• 拷贝 / 剪切 / 删除失败时，对上层发布的结果仍是"成功"：任务对话框、撤销（Ctrl+Z）栈、最近使用记录全部被污染。
• 数据丢失风险：剪切场景下 removeUrlsInClipboard(..., true) 会在源文件并未真正移动成功时清空剪贴板，用户失去"重新粘贴"的补救手段。

// 推荐做法：状态挂在 handle 上，随 handle 生命周期回收
struct JobResultState { bool ok { true }; QString errMsg; };
QHash<void *, JobResultState> m_jobStates;     // 配 QMutex 保护
// handleErrorNotify:   state.ok = false; state.errMsg = ...;
// handleFinishedNotify: publishJobResultEvent(..., state.ok, state.errMsg);

ssize_t bytesWritten = 0;
while (bytesWritten < actualBytesToWrite && !isStopped()) {
    ssize_t written = write(writer.fd, buffer + bytesWritten,
                            actualBytesToWrite - bytesWritten);
    if (written < 0) { /* EINTR / O_DIRECT 回退 / 报错 */ }
    // ← 缺少 written == 0 的处理，bytesWritten 不推进
}

• write() 返回 0 是合法返回（写入零字节），此时 bytesWritten 不前进，循环永久自旋。
• O_DIRECT 落盘、网络文件系统或磁盘写满等场景可触发。表现为：拷贝线程 100% CPU、进度条静止、任务无法取消（仅 isStopped() 能退出）。

int zeroWrites = 0;
while (bytesWritten < actualBytesToWrite && !isStopped()) {
    ssize_t written = write(writer.fd, buffer + bytesWritten,
                            actualBytesToWrite - bytesWritten);
    if (written > 0) { bytesWritten += written; zeroWrites = 0; continue; }
    if (written == 0) {
        if (++zeroWrites >= 3) { savedErrno = ENOSPC; goto handle_error; }
        continue;
    }
    if (errno == EINTR) continue;
    /* ... 原有错误与 O_DIRECT 回退逻辑 ... */
}

// pluginmanager_p.cpp:677 —— 只调用 stop()，未清理任何事件注册
pointer->d->plugin->stop();
pointer->d->plugin = nullptr;
pointer->d->state  = PluginMetaObject::State::kStoped;
if (!pointer->d->isVirtual && !pointer->d->loader->unload())   // ← .so 被卸载
    return false;

// eventdispatcher.h:52 —— handler 以裸指针 obj 捕获
auto func = [obj, method](const QVariantList &args) -> QVariant {
    EventHelper<decltype(method)> helper = (EventHelper<decltype(method)>(obj, method));
    return helper.invoke(args);                 // obj 已析构 → UAF
};
handlerList.push_back(EventHandler<Listener> { obj, memberFunctionVoidCast(method), func });

• 框架提供 LifeCycle::shutdownPlugin()（单个插件卸载）的公开能力，但该路径不设置 g_shuttingDown 标志，因此 EventDispatcher::dispatch 的关停短路保护（eventdispatcher.cpp:25）不生效。
• 卸载后任意一次 publish 都会经 EventHelper 调用已析构对象，且函数体所在 .so 已被 unload() 解除映射 → 确定性崩溃。

// EventDispatcher：调用前判活
for (const auto &h : handlersCopy)
    if (h.objectIndex && h.handler)          // QPointer 语义
        h.handler(params);

// accesscontroldbus.cpp:103 —— D-Bus 服务主线程，阻塞 read，无 O_NONBLOCK、无 poll 超时
QByteArray buffer;  char readBuffer[1024];  ssize_t bytesRead;
while ((bytesRead = read(fd, readBuffer, sizeof(readBuffer))) > 0) {
    buffer.append(readBuffer, bytesRead);      // 亦无长度上限
}

// deviceproxymanager.cpp:35 —— 从文件操作 UI 线程调用
auto &&reply = d->devMngDBus->QueryBlockDeviceInfo(id, reload);
reply.waitForFinished();                        // 无参数 = 无限等待

• 调用方不关闭管道写端时，read 永久阻塞 → 整个 accesscontrol 服务不再响应任何 D-Bus 请求；同时 buffer 无上限，存在内存耗尽风险。
• udisks / tag / vault 等 daemon 无响应或总线拥塞时，文件管理器主线程永久挂起（非卡顿，是假死），窗口变灰无重绘。
• tagproxyhandle 的 20 余次同步 D-Bus 调用位于标签读写路径，属于高频 UI 操作。

// 统一超时常量与降级
static constexpr int kDBusTimeoutMs = 5000;
if (!reply.isFinished() && !reply.waitForFinished(kDBusTimeoutMs)) {
    fmWarning() << "DBus timeout:" << iface << method;
    return {};                       // 返回空值，由调用方走 fallback
}

// fileinfohelper.cpp:42
pool.setMaxThreadCount(std::max(FileUtils::getCpuProcessCount(), 10));

// fileinfohelper.cpp:54 —— 在池任务内无限轮询，无超时、无 stoped 检查
auto resluts = asyncInfo->cacheAsyncAttributes();
while (resluts == 0) {
    QThread::msleep(50);
    resluts = asyncInfo->cacheAsyncAttributes();
}

• cacheAsyncAttributes() 返回 0 表示"属性尚未就绪"。在 SMB / NFS 挂载不可达、或 gvfs 后端挂起时，该值可长期保持 0 → 池任务永不返回。
• 由于池上限仅 max(CPU, 10)，累计 10 个此类任务即可令 pool 彻底饥饿：后续所有文件的缩略图、MIME 探测、属性刷新全部排队，界面表现为"文件图标永远不出现 / 属性面板一直转圈"。
• 循环内未检查 stoped，即使进入退出流程也无法中止。

QElapsedTimer t; t.start();
auto results = asyncInfo->cacheAsyncAttributes();
while (results == 0 && !stoped && t.elapsed() < kAttrWaitTimeoutMs /*5000*/) {
    QThread::msleep(20);
    results = asyncInfo->cacheAsyncAttributes();
}
if (results == 0) {                       // 超时：不再占用池线程
    checkInfoRefresh(asyncInfo);
    return;
}

// canvasproxymodel.cpp:486 —— fileMap 是哈希，却用 fileList.indexOf 反查行号
if (d->fileMap.contains(url)) {
    int row = d->fileList.indexOf(url);      // O(n)
    return createIndex(row, column);
}
// :693 data() → :695 mapToSource(index) → :644 d->srcModel->index(url) → fileinfomodel.cpp:434 又一次 O(n)

每个可见项的每次 data() 调用耗时随文件数线性增长，绘制 N 项即 O(N²)。桌面 2000 个图标时，单次重绘的索引定位可达数百万次 QUrl 比较，滚动与拖拽明显掉帧；sort() 中 lessThan 亦内联查索引，排序再叠加一层 O(n·log n)·O(n)。

const QString &fs_type = QStorageInfo(targetUrl.path()).fileSystemType();   // 解析挂载表，每文件一次
if (fs_type == "vfat") {
    QString new_name = fileName;
    return new_name.replace(QRegularExpression("[\"*:<>?\\|]"), "_");        // 每文件编译一次正则
}

targetUrl 在一次任务内恒定，但结果被逐文件重算。QStorageInfo 需读取并解析挂载表，万级文件时额外引入数秒纯开销；正则编译同样是可完全消除的重复工作。

static const QRegularExpression kVfatForbidden(R"(["*:<>?\\|])");
if (m_targetFsType == QLatin1String("vfat"))
    return QString(fileName).replace(kVfatForbidden, "_");

QRegularExpression re("", QRegularExpression::NoPatternOption);
for (int i = 0; i < nameFilters.size(); ++i) {
    QString pattern = QRegularExpression::wildcardToRegularExpression(nameFilters.at(i));
    re.setPattern(pattern);                 // 每个文件 × 每个模式 = 重新编译
    ...
}

一次目录过滤的开销为 O(文件数 × 模式数) 次正则编译。含多个过滤模式的目录（如 *.txt;*.md;*.log）在数万文件下 CPU 占用显著。

// children 类型：QHash<QUrl, QHash<QUrl, SortInfoPointer>>
if (this->children.value(makeParentUrl(sortInfo->fileUrl())).contains(...)) {
    //     ^^^^^^^^^^^^^^^ 按值返回整个子哈希 → 深拷贝该目录全部条目

监控到 n 个文件变化即触发 n 次"整目录条目拷贝"，单次批量操作复杂度 O(n·目录大小)。大目录（万级条目）下复制粘贴、批量重命名会明显变慢。

// trashfileeventreceiver.cpp:246 —— 枚举回收站，逐项 O(n) 查重
auto url = FileUtils::bindUrlTransform(enumerator.next());
if (!allFilesList.contains(url)) { allFilesList.append(url); processedCount++; }

5 万项约 12 亿次 QUrl 比较：清空回收站、退出程序时明显卡顿。同文件 :53 处 future.waitForFinished() 无超时会进一步放大等待。

// :909 —— 固定 10ms 无条件延时 + 轮询替代 waitForDone
void FileOperateBaseWorker::waitThreadPoolOver() {
    if (!isStopped() && threadPool) QThread::msleep(10);
    while (threadPool && threadPool->activeThreadCount() > 0) QThread::msleep(10);
    applyAllPendingReplacements();
}
// :704 —— 跨任务共享的 bigFileCopy 标志，其余任务在此空转
while (bigFileCopy && !isStopped()) { QThread::msleep(10); }

① 轮询而非 waitForDone()，每次等待固定引入 10ms 延迟并持续唤醒 CPU；② 任一池线程阻塞（如 P0-5）则本函数永久死循环，任务无法结束；③ bigFileCopy 为静态共享，大文件拷贝期间其他任务每 10ms 空转。

// :462 —— 未启用 CollectFiles 时仍为每个条目构造 QString + QUrl
const QUrl entryUrl = QUrl::fromLocalFile(QString::fromUtf8(entryPath));
// :867 —— 每次进度回调把整个 ScanResult（含 allFiles 列表）按值投递到主线程
state.progressCallback(state.result);
// ScannerWorker::start 中 emit resultReady(result, false) → 跨线程队列 → 全量深拷贝

① 纯计数场景（统计目录大小）下每条目仍产生两次堆分配，百万文件量级浪费可观；② 进度信号每 500ms 触发一次，若开启 CollectFiles，每 500ms 深拷贝一次随文件数增长的 QList<QUrl>，累计复杂度 O(n²)。

// :798 columnToRole 内，每个单元格调用一次
WorkspaceEventSequence::instance()->doFetchCustomColumnRoles(...);   // 事件总线分发
getFileViewStateValue(dirRootUrl, "headerList");                     // 读设置 + toMap() 拷贝

滚动与重绘时，每个可见单元格触发一次事件总线分发 + 设置读取/字典拷贝。列表视图下成为绘制主开销。另 :1415 在 UI 线程对 smb/sftp 等远程 scheme 执行同步 updateAttributes()（网络 IO），切目录时阻塞界面。

discScanTimer->start(kTimerInterval);                        // 3000ms
const auto &info { DevProxyMng->queryBlockInfo(id) };        // UI 线程阻塞往返
// :231 —— 每次查询都做一次同步总线探测
return QDBusConnection::sessionBus().interface()->isServiceRegistered(kDeviceService);
// :499 —— 持写锁期间做阻塞 D-Bus（注释自承可能死锁）
QWriteLocker lk(&lock);  auto &&info = q->queryBlockInfo(id);

① 光驱扫描每 3s 阻塞 UI 线程一次；② initMounts 对 N 台设备逐个查询，每次叠加一次 isServiceRegistered 同步往返，设备枚举 O(N) 次同步总线调用；③ :499 写锁覆盖 D-Bus 往返，其余查询全部排队。

// eventdispatcher.h:198 —— publish 在读锁内取到 dispatcher 后立即解锁
QReadLocker lk(&rwLock);
auto dispatcher = dispatcherMap.value(type);
lk.unlock();                             // ← 锁已释放
return dispatcher->dispatch(...);        // dispatch 内部无任何锁

// eventdispatcher.cpp:30 —— 无锁拷贝正在被并发修改的 QList
auto filtersCopy  = filterList;
auto handlersCopy = handlerList;
// 而 subscribe → append → handlerList.push_back() 只受 rwLock 保护

EventDispatcher 自身没有互斥量（:119-121 仅有裸 QList）。一个线程 subscribe（持 rwLock 写 handlerList）与另一线程 publish → dispatch（无锁读同一 QList）并发时，QList 内部指针可被撕裂 → 崩溃或随机跳过 handler。异步 asyncPublish 走 QtConcurrent，该竞争窗口在正常使用中即可命中。

QWriteLocker wlk(&d->mainLock);
for (const auto &url : urls) {
    auto info = d->mainCache.take(url);            // 第一次取出，已从容器删除
    if (info)
        infos.insert(url, d->mainCache.take(url));  // ← 第二次 take 恒为 nullptr
}
if (infos.size() > 0)
    emit cacheDisconnectWatcher(infos);            // 投递的 map 全为空值

下游 disconnectWatcher()（infocache.cpp:59-62）以 if (!info) continue; 跳过空值，因此没有任何一次 reduceCacheInfoConnectSize() 会被执行，其后的 getCacheInfoConnectSize() <= 0 分支与 removeCacheWatcher() 成为死代码。后果：

• watcher 的引用计数只增不减，缓存失效时的按需释放完全失效；
• inotify 监视只能靠 kCacheFileWatcherCount = 5000 的上限被动淘汰，长期驻留大量 watch 句柄，并持续消耗 inotify 配额。

auto info = d->mainCache.take(url);
if (info)
    infos.insert(url, info);          // 使用已取出的 info

{
    QReadLocker lk(&d->mainLock);                     // ← 读锁
    for (const auto &info : d->mainCache) {
        if (info) info->setExtendedAttributes(type, QVariant());   // ← 写共享对象
    }
}

读锁允许多个读者并发进入，而此处遍历并修改每个 FileInfo 的扩展属性。与其它持读锁读取同一批 FileInfo 的线程（如 getCacheInfo 的调用方）构成数据竞争，可读到半更新的属性值，极端情况下触碰 Qt 容器内部指针导致崩溃。

// eventchannel.cpp:74 —— send 完全不持锁
if (!conn) { ... }
return conn(params);
// 而 setReceiver 在 receiverMutex 保护下重写 conn（eventchannel.h:67-71）

// devicewatcher.cpp:83 —— 池任务捕获 this 并拷贝共享容器，主线程同时增删
QThreadPool::globalInstance()->start([this] {
    auto blocks    = allBlockInfos;      // 主线程并发 insert/remove，无锁
    auto protocols = allProtocolInfos;
    ...
});

① 并发重连时 conn（std::function）读写竞争，可能调用已释放的可调用体；② devicewatcher 每周期无条件新建池任务，慢盘下任务堆积，多份任务并发读取正被主线程修改的 QHash → 崩溃；对象析构后任务仍持有 this → use-after-free。

QReadLocker lk(&rwLock);
qsizetype size { globalFilterMap.size() };
for (qsizetype i = 0; i != size; ++i) {
    auto key { globalFilterMap.keys()[i] };      // 每次迭代重建整个 key 列表
    if (key) {
        auto func { globalFilterMap.value(key) };
        lk.unlock();
        return func(type, params);               // ← 首个非空 key 直接 return
    }
}
return false;

① 语义错误：注册多个全局过滤器时，后续过滤器永远不会执行，安全/权限类拦截可能被静默跳过；② 循环内 keys()[i] 使 map 非空时每次发布产生 O(n²) 次分配。