在应用程序的故障排除或调试场景中，我偶尔会遇到希望得到一个流或日志来显示程序可能正在执行的所有文件系统变化的愿望。有时，应用程序有一些非常复杂的行为和基于可能被更改的配置文件内容的竞赛条件，以及类似的事情。这里的重点是要有一种方法来监控磁盘上文件的演变。
特别是我希望能转发文件的差异流。所以我的第一直觉是看文件监视工具，也许像fswatch这样的工具，其概念是使用任何相关的操作系统功能（FSEventskqueueinotify）来钩住一个目录，制作一个临时的完整的目录副本，然后当我们收到事件时，就用它来进行差异化处理。
这可能对很多事情都很有效，但在我着手实现之前，我想到这可能从根本上容易受到竞赛条件的影响，任何应用程序都可能快速地多次写入一个文件，而我的FS观察系统没有办法强制文件系统阻塞，直到它能够生成diff后再继续。所以这样就无法保证日志的 都 变更，尽管如果修改相关文件的进程是未知的或不可控的，这可能是唯一可行的方法。如何处理这个问题？
也许这并不是什么大问题，因为通常情况下，有足够的上下文来找出发生了什么事情，而不需要重型工具。但如果没有...
一旦修改文件所涉及的过程被知道了（这又是一个典型的非问题，虽然在Linux上有 auditd)我们可以只 strace 进程。
我想问题就在于，一旦我们发现它修改了一个文件，也许就会想办法暂停这个进程。以防它可能会立即再次修改该文件 以确保我们可以获得它刚刚改变的内容的差异。
在这一点上，我开始质疑一个工具的价值，它能做这么具体的事情...... 我认为有一种情况是，你有一个混乱的多个进程在以一种不可预测的方式修改文件，而这是有价值的，仅仅是为了追踪发生了什么，以什么顺序发生。但是，试图在进程写入后立即停止进程的概念似乎并不健全，因为它很可能会改变结果的行为（混沌理论和所有这些）。
我相信在相关进程上使用strace会让我们达到90%的目的，但最后10%的内容我仍然有点不清楚，如果我们能配置strace来追踪参数，应该就足够了，而且尽可能快地进行追踪应该能提高不干扰结果的几率。我觉得Linux下的各种跟踪工具可以在这里派上用场（同时也可以处理stracing进程本身就已经会让它们慢很多的事实）。