[wangrong1069]

Root Cause Analysis

relay_thread_func() in src/server/event-relay-dispatcher.c sends fs_event using sizeof(fs_event) (~4KB) as the send length, regardless of the actual path length. Since fs_event.path is a fixed gchar path[4096] buffer, every event transmits ~4KB of zero-padded data even when the actual path is typically 20–200 bytes. The root cause is a parameter selection error at line 82 — the sender passes the full struct size instead of computing the actual byte count needed.

Key evidence:

• src/server/event-relay-dispatcher.c:82 — event_relay_dispatcher_send(d->relay, ev, sizeof(fs_event)) uses fixed struct size
• src/server/fs-event.h:10-16 — fs_event contains gchar path[MAX_PATH_LEN] (4096 bytes fixed buffer)
• src/dispatcher/event_relay_dispatcher.c:138 — send(fd, buf, len, MSG_NOSIGNAL) directly uses the passed len

Fix

Replace sizeof(fs_event) with offsetof(fs_event, path) + strlen(ev->path) + 1 to transmit only the meaningful bytes (struct header + actual path string including null terminator). Added #include <stddef.h> for the offsetof macro.

Change Safety Assessment

Code Safety

• Risk Level: Low
• Target code was introduced in a single commit (e8e427c5, PMS BUG-370779) as initial implementation — sizeof(fs_event) was not a previous bug fix, so this change does not revert any historical fix
• relay_thread_func is only called via g_thread_new at line 140; no other callers affected
• SOCK_SEQPACKET preserves message boundaries — receivers get exactly the bytes sent; struct header fields and path string remain intact

Business Impact Scope

• Event relay module — file system events (create/modify/delete) forwarded to connected channel clients via the relay dispatcher worker thread
• No direct user-facing operation; the deepin-anything backend service monitors filesystem changes and notifies subscribed clients — this optimization reduces bandwidth without altering event content

Verification Suggestion

• Test file event forwarding with short paths (<100 bytes) and long paths (near 4096 bytes)
• Verify multi-client broadcast still works correctly

---

根因分析

src/server/event-relay-dispatcher.c 中 relay_thread_func() 使用 sizeof(fs_event)（约4KB）作为发送长度发送 fs_event，未根据实际路径长度计算。由于 fs_event.path 为固定 gchar path[4096] 缓冲区，每次事件转发都传输大量零填充无效数据，实际路径通常仅 20~200 字节。根因为第82行参数选择错误——发送方传入完整结构体大小而非计算实际需要的字节数。

关键证据：

• src/server/event-relay-dispatcher.c:82 — 使用固定结构体大小发送
• src/server/fs-event.h:10-16 — fs_event 含 gchar path[4096] 固定缓冲区
• src/dispatcher/event_relay_dispatcher.c:138 — send() 直接使用传入的 len 参数

修复方案

将 sizeof(fs_event) 替换为 offsetof(fs_event, path) + strlen(ev->path) + 1，仅传输有效字节（结构体头部 + 实际路径字符串含 null 终止符）。添加 #include <stddef.h> 以使用 offsetof 宏。

改动安全评估

代码安全评估

• 风险等级：低风险
• 目标代码在单次提交（e8e427c5，PMS BUG-370779）中引入，sizeof(fs_event) 为初始实现非此前 bug 修复产物，本次修改不撤销历史修复
• relay_thread_func 仅通过第140行 g_thread_new 调用，无其他调用者受影响
• SOCK_SEQPACKET 保留消息边界，接收端收到字节数等于发送长度，结构体头部字段和路径字符串完整

业务影响范围

• 事件分发模块 — 文件系统事件（创建/修改/删除）通过 relay dispatcher 工作线程转发至连接的客户端
• 无直接面向用户操作，deepin-anything 后台服务监控文件系统变化并通知订阅客户端，本次修改优化传输效率不影响事件内容

验证建议

• 测试短路径（<100字节）和长路径（接近4096字节）文件事件转发
• 验证多客户端同时连接时事件广播正常

Summary by Sourcery

Send filesystem events with their actual payload length to avoid transmitting unused path-buffer data.

Bug Fixes:

• Send filesystem relay events using the actual serialized header and path length instead of the full fixed-size event buffer.

Enhancements:

• Reduce unnecessary data transmitted for filesystem events while preserving the complete event path.

[sourcery-ai]

Sorry, we are unable to review this pull request

The GitHub API does not allow us to fetch diffs exceeding 300 files, and this pull request has 421

[github-actions]

TAG Bot

TAG: 7.1.0
EXISTED: no
DISTRIBUTION: unstable

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: lzwind, wangrong1069

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

[wangrong1069]

/forcemerge

[deepin-bot]

This pr force merged! (status: unstable)

[lzwind]

/retest