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