想弄个监控文件是否被修改的子程序,在windows下,我是用的WIN32_FIND_DATA和FindFirstFile 这两个API,到了LINUX下面,准备转成inotify,结果在这搞笑了~~
关于inotify的机制,很多人都讲过,我就不多说了。我这出现的问题是:
对文件是否被修改进行判断,需要用到inotify的IN_MODIFY文件系统事件。然而,我用gedit对该文件进行修改,不管怎么弄,都无法得到IN_MODIFY事件,而会得到IN_IGNORED事件(10进制值是 32768)。之后,inotify就不再通知任何文件事件了!可是如果用别的方法编辑文件,比如用输出重定向>>,文件的修改事件是可以正确得到的!
要搞明白这个奇怪的现象,需要知道vim,gedit类的文本编辑程序的工作原理。这些编辑器在编辑文件时,实际上是在该文件的一个副本中进行编辑的。当用户保存文件时,编辑器先对原文件进行了删除操作,随后将副本重命名为原文件。
由于编辑器先删除了原文件,inotify发现了文件被删除了,马上就会把针对该文件的watch删掉,所以inotify通知了IN_IGNORED事件后就不再通知任何事件了!
不过还好有IN_IGNORED事件,我们还是可以做一些补救!
关于inotify的机制,很多人都讲过,我就不多说了。我这出现的问题是:
对文件是否被修改进行判断,需要用到inotify的IN_MODIFY文件系统事件。然而,我用gedit对该文件进行修改,不管怎么弄,都无法得到IN_MODIFY事件,而会得到IN_IGNORED事件(10进制值是 32768)。之后,inotify就不再通知任何文件事件了!可是如果用别的方法编辑文件,比如用输出重定向>>,文件的修改事件是可以正确得到的!
要搞明白这个奇怪的现象,需要知道vim,gedit类的文本编辑程序的工作原理。这些编辑器在编辑文件时,实际上是在该文件的一个副本中进行编辑的。当用户保存文件时,编辑器先对原文件进行了删除操作,随后将副本重命名为原文件。
由于编辑器先删除了原文件,inotify发现了文件被删除了,马上就会把针对该文件的watch删掉,所以inotify通知了IN_IGNORED事件后就不再通知任何事件了!
不过还好有IN_IGNORED事件,我们还是可以做一些补救!
下面是我的代码:
#include <stdio.h>
#include <unistd.h>