我正在开发一个小型NodeJS应用程序，它基本上用作基于浏览器的桌面搜索，用于基于LAN的服务器，用户可以查询多个。局域网上的用户都可以访问该服务器上的共享文件夹，传统上只用于将文件放在该文件夹中以便在每个人之间共享，我希望保持该过程相同。
我遇到的第一个解决方案是其他stackoverflow问题中涉及的fs.watchFile。在第一个question用户Ivo Wetzel中指出，在Linux系统上，fs.watchFile使用inotify，但是，fs.watchFile不应该用于大量的文件/文件夹。
关于fs.watchFile用户question的另一个tjameson首先重申，在fs.fileWatch上将使用Linux inotify，并建议仅使用node-inotify-plusplus和{{3的组合但是再次说明这种方法不应该用于大量文件。通过评论和响应，他建议只观察目录的修改时间，然后重新扫描相关目录以进行文件更改。
我最大的障碍似乎是，即使有tjameson的建议，监控文件夹的数量仍然存在严格的限制（其中有很多并且正在增长）。此外，它必须以递归方式完成，因为目录树有点深，也可能在较低的分支处进行更改，因此我必须在每个文件夹级别监视以下内容（或者监视文件夹的修改时间，然后扫描以找出发生的事情）：
假设inotify的限制与上面所说的一致，那么当我拥有大量嵌套子文件夹时，这对我来说似乎可能是太多的监视器。真正令人敬畏的方式看起来会涉及node-walk，我随后将其作为kqueue中更好的fs.fileWatch的讨论话题。
我似乎很清楚，保留相关文件和文件夹信息的数据库是查询方面的适当行动方案，但保持该数据库与所关注目录下的文件系统的实际状态保持同步将是挑战。
社区的想法是什么？是否有一个更好或众所周知的解决方案来攻击我不知道的这个问题？最好只观看所有感兴趣的目录，例如单个变化，例如修改时间，然后扫描，找出发生了什么？是否更好地观察所有相关的inotify警报并适当修改数据库？这不是像我这样的农民可以解决的问题吗？
答案 0 :(得分：2)
看看monit。我使用它监视文件以查找我的开发环境中的更改，并在相关项目文件更改时重新启动我的节点进程。
答案 1 :(得分：0)
我建议你看一下Dropbox API。
我在客户端实现了与ruby类似的东西，在服务器端实现了nodejs。 最好的方法是保持哈希检查文件或文件夹是否发生了变化。