使用inotify监控目录时链表事件丢失问题及操作序列检测需求

一、链表事件丢失的核心排查点 #

虽然你提到单独测试链表功能正常，但结合inotify的事件处理场景，大概率是链表操作与inotify流程的结合出了内存/指针管理问题，常见坑点：

• 栈内存误用：如果链表节点是在事件处理函数的栈上定义（比如struct EventNode node;），函数返回后栈内存被释放，后续访问必然出现数据丢失/乱码。必须用malloc在堆上分配节点内存。
• 头指针未持久化：如果链表头是局部变量，每次进入事件处理函数都会被重置为NULL，导致之前的节点完全无法访问。要确保头指针是全局变量、静态变量，或者通过指针传递到节点新增函数中。
• 节点插入逻辑断裂：插入新节点时，只修改了新节点的next指针，但未将前一个节点的next指向新节点，导致链表变成"单个节点链"，只能访问最后插入的节点。
• inotify事件未全量读取：如果事件缓冲区设置过小，或者处理时没循环读取所有pending事件，会导致部分事件被遗漏，看起来像链表丢失（实际是事件没被捕获）。必须循环处理read返回的所有事件：

  char buf[4096];
  ssize_t len;
  while ((len = read(fd, buf, sizeof(buf))) > 0) {
      struct inotify_event *event = (struct inotify_event *)buf;
      // 遍历所有事件
      while (len >= sizeof(struct inotify_event)) {
          // 处理当前event逻辑
          size_t event_size = sizeof(struct inotify_event) + event->len;
          len -= event_size;
          event = (struct inotify_event *)((char *)event + event_size);
      }
  }
  

二、更高效的特定序列检测方案 #

用链表存储所有事件再匹配的方式效率低且易混乱，推荐状态机模式，针对每个目标文件独立维护状态：

状态定义 #

• STATE_IDLE：初始状态，等待原文件读取事件
• STATE_READ_DONE：已捕获原文件完整读取，等待创建.locked文件
• STATE_LOCKED_CREATED：已创建.locked文件，等待写入加密内容
• STATE_LOCKED_WRITTEN：已写入.locked文件，等待删除原文件
• STATE_SEQUENCE_COMPLETED：目标操作序列完成

实现思路 #

1. 用哈希表（或简单数组映射）跟踪每个文件的状态，键为文件名，值为当前状态+最后事件时间。
2. 处理inotify事件时，按事件类型+文件名更新对应状态：
   • 捕获IN_ACCESS且文件为example.txt时，切换到STATE_READ_DONE（可通过1秒内多次读取事件判断为完整读取）
   • 捕获IN_CREATE且文件为example.txt.locked时，切换到STATE_LOCKED_CREATED
   • 捕获IN_MODIFY且文件为example.txt.locked时，结合文件大小是否稳定判断写入完成，切换到STATE_LOCKED_WRITTEN
   • 捕获IN_DELETE且文件为example.txt时，若当前状态是STATE_LOCKED_WRITTEN，则判定序列完成
3. 增加超时机制：若某个状态超过5秒未切换，重置为STATE_IDLE，避免异常事件卡住状态。

简化代码片段 #

typedef enum {
    STATE_IDLE,
    STATE_READ_DONE,
    STATE_LOCKED_CREATED,
    STATE_LOCKED_WRITTEN,
    STATE_SEQUENCE_COMPLETED
} FileState;

typedef struct {
    char filename[256];
    FileState state;
    time_t last_event_time;
} FileTrack;

// 用数组跟踪文件状态（实际场景建议用哈希表）
#define MAX_TRACK 10
FileTrack track_list[MAX_TRACK] = {0};

void handle_inotify_event(struct inotify_event *event) {
    if (event->len == 0) return;
    char *curr_name = event->name;
    FileTrack *track = NULL;

    // 查找或初始化文件跟踪项
    for (int i = 0; i < MAX_TRACK; i++) {
        if (strcmp(track_list[i].filename, curr_name) == 0) {
            track = &track_list[i];
            break;
        }
    }
    if (!track) {
        for (int i = 0; i < MAX_TRACK; i++) {
            if (track_list[i].filename[0] == '\0') {
                strncpy(track_list[i].filename, curr_name, 255);
                track_list[i].state = STATE_IDLE;
                track = &track_list[i];
                break;
            }
        }
    }
    if (!track) return;

    track->last_event_time = time(NULL);
    // 更新状态逻辑
    if (strcmp(curr_name, "example.txt") == 0) {
        if ((event->mask & IN_ACCESS) && track->state == STATE_IDLE) {
            track->state = STATE_READ_DONE;
        } else if ((event->mask & IN_DELETE) && track->state == STATE_LOCKED_WRITTEN) {
            track->state = STATE_SEQUENCE_COMPLETED;
            printf("目标操作序列已完成！\n");
            // 触发后续处理逻辑
        }
    } else if (strstr(curr_name, ".locked") != NULL) {
        char base_name[256];
        strncpy(base_name, curr_name, strlen(curr_name) - 7);
        base_name[strlen(curr_name)-7] = '\0';
        if (strcmp(base_name, "example.txt") == 0) {
            if ((event->mask & IN_CREATE) && track->state == STATE_READ_DONE) {
                track->state = STATE_LOCKED_CREATED;
            } else if ((event->mask & IN_MODIFY) && track->state == STATE_LOCKED_CREATED) {
                // 检查文件大小是否稳定，判断写入完成
                struct stat st;
                if (stat(curr_name, &st) == 0 && st.st_size > 0) {
                    track->state = STATE_LOCKED_WRITTEN;
                }
            }
        }
    }

    // 超时重置状态
    if (difftime(time(NULL), track->last_event_time) > 5) {
        track->state = STATE_IDLE;
    }
}

三、额外注意事项 #

• inotify的IN_ACCESS会在每次读取时触发，无法直接判断"完整读取"，可通过时间窗口（比如1秒内多次读取视为一次完整操作）优化判断。
• 处理文件删除事件后，要及时从跟踪列表中移除对应项，避免无效内存占用。
• 若监控目录有多个目标文件，状态机模式的扩展性远优于链表匹配，每个文件独立维护状态，互不干扰。

内容的提问来源于stack exchange，提问作者Jukeland