Windows上有类似inotify的东西吗？答案

【问题标题】：Is there anything like inotify on Windows?Windows上有类似inotify的东西吗？
【发布时间】：2011-03-31 20:30:54
【问题描述】：

对于 Linux 操作系统，有一个 ionotify 子系统，它会通知应用程序文件系统的更改。

但是，我主要是 Windows 用户，所以我想知道是否有类似的方法来监视文件系统更改？

【问题讨论】：

我不认为这样的问题是题外话。该问题要求使用与任何工具/软件库都大不相同的 OS API。可能它的措辞可能不同，例如当特定文件/文件被修改时如何在 Windows 应用程序中获得通知。
投票重新开放：问题是要求提供与特定操作系统 API 类似的替代方案，并形象地对我说：“我来自英国，我用叉子吃饭，在日本用什么器具我是否以类似的方式使用？”使用该类比的公认答案是“使用筷子”。

【解决方案1】：

如果您使用的是 .net，请使用 FileSystemWatcher。更多信息在这里：http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx

如果您使用的是 C，请使用 FindFirstChangeNotification、FindNextChangeNotification、ReadDirectoryChangesW。更多信息在这里：http://msdn.microsoft.com/en-us/library/aa365261(VS.85).aspx

在 OSX 上，相关的 api 是 fsevents api。

它们彼此之间都有微妙的不同，而且它们在极端情况下的可靠性都值得怀疑。通常，您不能 100% 地依赖这些 api 来获得所有更改的完整视图。大多数使用文件系统监控的人将其与定期扫描相结合，以弥补推送 api 中丢失或不完整的信息。

【讨论】：

您能否引用“在边缘情况下 inotify 的可靠性有问题？
如果 fs watcher api 的使用者读取事件的速度比其他进程生成事件的速度慢，则内核要么需要在其他（可能具有更高优先级的）进程中保留文件系统修改，要么允许缓冲区无限增长。 inotify 的缓冲区深度（如手册页中所述）由 /proc/sys/fs/inotify/max_queued_events 控制。除此之外，您还会收到 IN_Q_OVERFLOW 通知——这很好，但您仍然需要不时重新扫描。
啊哈，我最近在排队阅读。我认为这种极端情况将取决于您正在监视多少文件，并且还取决于跟踪所有更改是否至关重要，或者是否会遗漏一些。但这是一个很好的观点。谢谢:)
@blucz 我想知道内核人员如何解决这些情况。很高兴知道他们这样做，让人们对设计和实施更有信心。

【解决方案2】：

参见FindFirstChangeNotification API，或.NET 对应的FileSystemWatcher

【讨论】：

【解决方案3】：

看看这个：inotify-win, a port of the inotifywait tool for Windows

还有这个：inotify-tools

【讨论】：

【解决方案4】：

JNotify 或 FileMon 来自 Microsoft。

【讨论】：

JNotify 非常适合我，因为我需要跨平台兼容性。我什至能够编写一个在 cygwin、mac 和 linux 中工作的 bash 脚本，前提是 JAVA_HOME 设置正确。当客户说“它删除了我的文件！”时，这对调试客户机器上的问题很有帮助。我实际上可以查看日志并尝试弄清楚这是如何/何时发生的。
FileMon 现在是 ProcessMonitor technet.microsoft.com/en-us/sysinternals/bb896645

【解决方案5】：

有点晚了，但是……

Windows 具有类似于 OSX 事件的功能，您可以在不运行应用程序的情况下监控事件。 Windows USN 日志跟踪所有文件更改。 Jeffrey Richter（Advanced Windows 的作者）写了一个terrific article，其中包含 MSDN Journal 的工作示例。更新：article 现在来自 archive.org，因为 MSJ 不再在 MS 在线。

MSDN documentation for USN Change Journals.

如果您正在构建需要监控整个卷的备份工具或索引等应用程序，USN 更改日志可能会更好。

【讨论】：

USN 期刊的方式有什么不同吗，依靠它是否可以避免 FileSystemWatcher|FindFirstChangeNotification PhillipBrandonHolmes 是 speaking of 的错误行为？
我已经有一段时间没有使用它了，但它不使用 FileSystemWatcher 或 FindFirstChangeNotification。我开始在 Go 中编写一个 Windows 事件观察器，主要基于 Jeffery Richter 的示例。从我做的一些测试来看，它坚如磐石，没有遗漏任何东西，类似于 OS X 中的 fsevents。要点在这里：gist.github.com/pkrnjevic/7219861
@PeterKrnjevic 你能更新 Jeffrey Richter 文章的链接吗？
@SOUser，由于 MS bitrot，文章现在链接自 archive.org。

【解决方案6】：

FileSystemWatcher() 不可靠主要是因为它对观察者缓冲区的错误处理或多或少是不完整的。由于缺少路径和详细的错误处理信息，Microsoft 无法让您恢复或手动轮询工作目录。

Windows 的 JNotify 也不可靠，因为这个错误 ^ 源自 win32。 JNotify 使用 win32。所以，它与 FileSystemWatcher() 没有什么不同。

【讨论】：

思考如何设计角色来解决这个类似“速度”/“竞赛”/“溢出”的问题，我想知道内核是如何做到的。有趣的。这件事也发生在网络和日志记录中。这个问题有名字吗？
是的，它的名字是“bug”。迄今为止，Microsoft 创建的每个操作系统中都存在该错误 (win32)。这使得任何 Microsoft 操作系统都不适合文件监视类型的解决方案。你必须去 *nix 才能完成它。有时我认为他们出于安全原因故意留下了这个缓冲区溢出。
哈哈..是的..它的名字是故意的集群kludge，这样微软的文件系统就不会被故意监视。这是他们出于安全考虑而留下的错误。

【解决方案7】：

我做了一些搜索，我似乎记得在 Windows 上看到过类似的东西。有 FileSystemWatcher 用于 .NET。它主要用于 NT 或 XP 及更高版本。

【讨论】：

它通常只在 NTFS 文件系统上可用，而不是在 FAT16、FAT32 甚至新的 exFAT 上。

【解决方案8】：

试试Java File Notification Library

【讨论】：