Linux inotifywait 如何只捕获目录新增文件：事件过滤、递归范围与重复通知

线上导入服务偶尔会多处理同一个文件，查看日志后发现，目录监控脚本把“文件刚创建”和“文件仍在写入”混在了一起。用 inotifywait 只捕获新增文件，关键是把事件过滤收窄到 -e create，再明确是否需要 --recursive；如果要等文件写完，还要单独处理 CLOSE_WRITE。

先用单层目录和 -e create 验证新增事件，再根据子目录需求决定是否加 --recursive；不要把所有事件都交给后续脚本。

先把“新增”与“写完”分开

假设导入服务只接收 /var/app/inbox 根目录里的新文件。创建事件表示目录项出现了，但不表示文件内容已经完整。一个上传程序可能先创建空文件，再连续写入，最后关闭文件。如果消费者在第一步就读取，看到的可能只是半截内容。

因此这篇只解决“如何稳定捕获新增目录项”，并把等待写完列为后续选择。先把边界做小，排错时才知道是哪一层放大了事件数量。

输出链路：从 inotifywait 到可处理路径

最小监听命令如下：

inotifywait -m -e create --format '%w%f' /var/app/inbox

inotifywait 读取内核通知，--format 把目录和文件名拼成一行，最终输出落在 /var/app/inbox 这条监控路径下。后续脚本可以按整行读取，避免再猜文件名从哪里来。

如果命令输出了 /var/app/inbox/report.csv，这只能证明目录项产生了 create 通知。要判断文件是否能立即读取，仍需结合写入方行为复测。

范围选择：单层监听还是递归监听

不加 --recursive 时，监听范围就是 /var/app/inbox 这一层；文件被放进 /var/app/inbox/2026-08，不会因为父目录被监听而自动变成目标事件。需要覆盖子目录时才加：

inotifywait -m --recursive -e create --format '%w%f' /var/app/inbox

递归监听扩大了目录树，也扩大了事件处理量。值班时先确认业务是否真的把文件分层存放，再决定是否启用它。

为什么日志里会出现重复或过早处理

-e create 只筛选创建目录项；如果脚本同时监听了写入、移动和关闭，就可能把一次文件投递拆成多个阶段。尤其是“临时文件写完后改名”的上传方式，真正适合消费的信号可能是目标文件的 CLOSE_WRITE，也可能是一次 moved_to，要看生产方的落盘协议。

这里别急着把所有事件都加进来。先运行最小命令，手动复制一个小文件，再记录命令输出和导入程序读取时刻。若 create 发生后文件仍在增长，就把消费动作延后，或让生产方采用临时名写入、完成后改名的约定。

一组可复查的验证动作

1. 确认工具存在：运行 command -v inotifywait，记录实际路径。
2. 在一个终端运行 inotifywait -m -e create --format '%w%f' /var/app/inbox。
3. 另一个终端执行 cp sample.csv /var/app/inbox/，核对输出是否只出现目标路径。
4. 若需要子目录，再复制到 /var/app/inbox/2026-08/，比较加不加 --recursive 的差异。
5. 检查文件大小变化；若 create 输出早于写入结束，消费者不得把 create 当成“内容已完整”。

把命令交给长期运行脚本前的边界

-m 会持续运行，终端中断或服务管理器停止进程后监听才会结束。生产环境应明确 stdout 去向、重启策略和磁盘队列；不要在事件回调里直接假定文件一定存在或一定可读。对大目录树，先评估递归范围和事件速率，再决定是否需要去重队列。

常见问题

只想监听根目录，应该加 --recursive 吗？

不应该。根目录单层监听省掉子目录事件，只有目录层级本身是业务输入时才启用 --recursive。

create 事件能代表文件上传完成吗？

不能。它代表目录项创建；文件仍可能处于写入过程，是否使用 CLOSE_WRITE 或改名完成信号要由落盘方式决定。

总结

把 inotifywait 当作事件入口，而不是完整的文件入库协议：-e create 缩小事件范围，--recursive 决定目录边界，--format 固定传给消费者的路径格式。先在 /var/app/inbox 做一次可复现验证，再接入长期运行脚本，过早消费和重复通知会更容易定位。