检测文件是不是被修改,即使在最后一秒内,也没有散列?
Posted
技术标签:
【中文标题】检测文件是不是被修改,即使在最后一秒内,也没有散列?【英文标题】:Detect if a file was modified, even within the last second, without hashing?检测文件是否被修改,即使在最后一秒内,也没有散列? 【发布时间】:2010-11-23 12:23:18 【问题描述】:这适用于 Mac,但也可能适用于 Linux,所以我将其标记为这样。
我在一个目录中递归并得到一棵树,带有文件系统属性。
然后,每次窗口重新聚焦时,我都会再次(一次又一次)递归。当我阅读目录时,我正在寻找任何被修改并需要对其采取行动的文件。
想到的最明显的事情是比较每个文件的修改日期,但是我的单元测试证明这不可靠,因为测试本身在不到一秒的时间内执行......结果是我的测试改变了文件被视为未修改(因为它只精确到 1 秒)。
到目前为止,我的解决方法是同时比较文件大小,但这会带来风险,即如果文件被更改,并且结果大小相同,它也将未被检测到。
远离散列每个文件,这是不可行的(递归整个目录树时太慢了),还有其他我可以使用 HFS/HFS+ 提供的东西吗?像附加到文件的某种版本号/修改计数?我不担心,尽管实际上文件更改的速度与我的单元测试更改它们一样快的边缘情况在实际用例中不太可能成为问题。
【问题讨论】:
【参考方案1】:实时、最小负载解决方案:
Linux:inotify 苹果机:kqueue请注意,您关于修改时间解决的问题仅针对 HFS+。
最常用的跨平台解决方案是File Alteration Monitor。
其他链接:
detect if something is modified in directory, and if so, backup - otherwise do nothing c program for directory monitor http://en.wikipedia.org/wiki/Inotify http://en.wikipedia.org/wiki/HFS%2B http://en.wikipedia.org/wiki/Kqueue【讨论】:
美女! :) 有人提到了 inotify,然后我在 Mac 上找到了 FSEvents 框架,但它不能处理文件,只能处理目录。然后我放弃了。 kqueue 确实存在于系统中,所以这应该可以很好地解决问题,并且会比我目前的方法占用更少的 I/O 和 CPU。以上是关于检测文件是不是被修改,即使在最后一秒内,也没有散列?的主要内容,如果未能解决你的问题,请参考以下文章