inotifywait需明确指定事件类型：监控目录用-e create（加-r递归）捕获新建文件，监控文件用-e modify捕获内容修改；modify触发需写入落盘，rename操作触发move_to而非modify；常见失效因缺-m、路径错误、权限不足或事件掩码不全。
inotifywait 能直接监控文件创建和内容修改，但必须明确指定 -e create 和 -e modify 事件，且对目录和文件的监控行为不同——监控目录才能捕获子项创建，监控文件本身才能捕获其内容修改。
监控目录时如何捕获新文件创建
目录本身不产生 modify 事件，只有其子项增删改才会触发 create、delete、move 等事件。若只写 inotifywait -e modify /path 监控目录，实际什么也收不到。
- 必须用
-e create（或组合如-e create,modify）才能捕获新建文件 - 需加
-r才能递归监听子目录下的创建行为 -
--format '%w%f %e'可输出完整路径和事件名，避免仅靠默认格式难以区分目标 - 示例：
inotifywait -m -r -e create,modify /tmp/testdir/ --format '%w%f %e'
监控单个文件时 modify 事件的实际触发条件
modify 事件只在文件内容被写入并刷新（如 write() + fsync() 或关闭文件描述符）后才发出，不是每次 echo "x" >> file 都立即触发——取决于程序是否真正落盘。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 用
dd、vim、cp修改文件通常会触发modify - 某些编辑器（如
nano）可能先写临时文件再rename()，此时触发的是move_to而非modify - 如果想同时捕获“内容改”和“文件换”，应叠加
-e modify,move_to - 注意：
attrib（如chmod）和modify是分开事件，不加就收不到
常见误配导致监控“看似失效”的原因
多数失败不是 inotifywait 有问题，而是事件类型、路径或权限没对上。
- 忘记
-m：默认只等一次事件就退出，必须加才能持续监听 - 路径不存在或无读取权限：inotifywait 启动时即报错
Cannot watch /xxx: No such file or directory或静默失败 - 监控符号链接但未加
-d：默认跟随链接，若目标不可达则失败；加-d可监控链接自身变化 - 内核限制超限：当报错
No space left on device（实际是 inotify 资源耗尽），需调大fs.inotify.max_user_watches - 排除正则写错：如
--exclude 'node_modules|\.git'中点没转义，会导致匹配失效
生产环境建议搭配的最小健壮结构
裸用 inotifywait | while read 在高频率事件下容易丢事件（bash while 循环处理慢于事件生成），真要可靠，得控制节奏或换方案。
- 加
--buffer（inotifywait 4.0+）启用内核事件缓冲，减少丢失 - 用
-t 10分段轮询 + 重试逻辑，比纯-m更易容错 - 关键任务别只依赖 inotifywait：配合
find -mmin -1定期兜底校验 - 若需知道哪个进程改了文件，
inotifywait不行，得换fatrace或auditctl
最易被忽略的一点：inotify 监控的是 inode 层操作，不感知逻辑层重命名或硬链接——比如 mv a b 在同一文件系统内只是目录项更新，不会触发 modify，但会触发 move_from 和 move_to。要覆盖这类行为，事件掩码必须写全，不能只盯 modify。
