- 论坛徽章:
- 1
|
原帖由 Bayweb 于 2006-8-27 19:49 发表
>>
>>
>>Linux下可以通过比较目录文件的内容是否一样（.文件）实现
>>1.事先将文件列表或者目录文件储存起来（例如文件、程序变量）
>>2.定时获得当前文件信息，进行比较
& ...
这个方法很土（尽管也许它很管用），
自从 linux 2.4 之后，linux 内核就支持一套监视目录的接口，
楼主可以 man 一下 fcntl，下面是从我的机器上摘录下来的部分：
- FCNTL(2) Linux Programmer's Manual FCNTL(2)
- NAME
- fcntl - manipulate file descriptor
- .....<omit>.....
- File and directory change notification (dnotify)
- F_NOTIFY
- (Linux 2.4 onwards) Provide notification when the directory
- referred to by fd or any of the files that it contains is
- changed. The events to be notified are specified in arg, which
- is a bit mask specified by ORing together zero or more of the
- following bits:
- Bit Description (event in directory)
- -------------------------------------------------------------
- DN_ACCESS A file was accessed (read, pread, readv)
- DN_MODIFY A file was modified (write, pwrite,
- writev, truncate, ftruncate)
- DN_CREATE A file was created (open, creat, mknod,
- mkdir, link, symlink, rename)
- DN_DELETE A file was unlinked (unlink, rename to
- another directory, rmdir)
- DN_RENAME A file was renamed within this
- directory (rename)
- DN_ATTRIB The attributes of a file were changed
- (chown, chmod, utime[s])
- (In order to obtain these definitions, the _GNU_SOURCE feature
- test macro must be defined.)
- Directory notifications are normally "one-shot", and the appli-
- cation must re-register to receive further notifications.
- Alternatively, if DN_MULTISHOT is included in arg, then notifi-
- cation will remain in effect until explicitly removed.
- A series of F_NOTIFY requests is cumulative, with the events in
- arg being added to the set already monitored. To disable noti-
- fication of all events, make an F_NOTIFY call specifying arg as
- 0.
- Notification occurs via delivery of a signal. The default sig-
- nal is SIGIO, but this can be changed using the F_SETSIG command
- to fcntl(). In the latter case, the signal handler receives a
- siginfo_t structure as its second argument (if the handler was
- established using SA_SIGINFO) and the si_fd field of this struc-
- ture contains the file descriptor which generated the
- notification (useful when establishing notification on multiple
- directories).
- Especially when using DN_MULTISHOT, a POSIX.1b real time signal
- should be used for notification, so that multiple notifications
- can be queued.
- NOTE: New applications should consider using the inotify inter-
- face (available since kernel 2.6.13), which provides a superior
- interface for obtaining notifications of file system events.
- See inotify(7).
上面把这套机制基本上说清楚了。
另外还提到，自从 2.6.13 之后，kernel 又提供了一套更高级、更方便的接口，下面是它的文档：
- INOTIFY(7) Linux Programmer's Manual INOTIFY(7)
- NAME
- inotify - monitoring file system events
- DESCRIPTION
- The inotify API provides a mechanism for monitoring file system events.
- Inotify can be used to monitor individual files, or to monitor directo-
- ries. When a directory is monitored, inotify will return events for
- the directory itself, and for files inside the directory.
- The following system calls are used with this API: inotify_init(), ino-
- tify_add_watch(), inotify_rm_watch(), read(), and close().
- inotify_init(2) creates an inotify instance and returns a file descrip-
- tor referring to the inotify instance.
- inotify_add_watch(2) manipulates the "watch list" associated with an
- inotify instance. Each item ("watch") in the watch list specifies the
- pathname of a file or directory, along with some set of events that the
- kernel should monitor for the file referred to by that pathname. ino-
- tify_add_watch() either creates a new watch item, or modifies an exist-
- ing watch. Each watch has a unique "watch descriptor", an integer
- returned by inotify_add_watch() when the watch is created.
- inotify_rm_watch(2) removes an item from an inotify watch list.
- When all file descriptors referring to an inotify instance have been
- closed, the underlying object and its resources are freed for re-use by
- the kernel; all associated watches are automatically freed.
- To determine what events have occurred, an application read(2)s from
- the inotify file descriptor. If no events have so far occurred, then,
- assuming a blocking file descriptor, read() will block until at least
- one event occurs.
- Each successful read() returns a buffer containing one or more of the
- following structures:
- struct inotify_event {
- int wd; /* Watch descriptor */
- uint32_t mask; /* Mask of events */
- uint32_t cookie; /* Unique cookie associating related
- events (for rename(2)) */
- uint32_t len; /* Size of 'name' field */
- char name[]; /* Optional null-terminated name */
- };
- wd identifies the watch for which this event occurs. It is one of the
- watch descriptors returned by a previous call to inotify_add_watch().
- mask contains bits that describe the event that occurred (see below).
- cookie is a unique integer that connects related events. Currently
- this is only used for rename events, and allows the resulting pair of
- IN_MOVE_FROM and IN_MOVE_TO events to be connected by the application.
- The name field is only present when an event is returned for a file
- inside a watched directory; it identifies the file pathname relative to
- the watched directory. This pathname is null-terminated, and may
- include further null bytes to align subsequent reads to a suitable
- address boundary.
- The len field counts all of the bytes in name, including the null
- bytes; the length of each inotify_event structure is thus sizeof(ino-
- tify_event)+len.
- inotify events
- The inotify_add_watch(2) mask argument and the mask field of the ino-
- tify_event structure returned when read(2)ing an inotify file descrip-
- tor are both bit masks identifying inotify events. The following bits
- can be specified in mask when calling inotify_add_watch() and may be
- returned in the mask field returned by read():
- Bit Description
- IN_ACCESS File was accessed (read) (*)
- IN_ATTRIB Metadata changed (permissions, timestamps,
- extended attributes, etc.) (*)
- IN_CLOSE_WRITE File opened for writing was closed (*)
- IN_CLOSE_NOWRITE File not opened for writing was closed (*)
- IN_CREATE File/directory created in watched directory (*)
- IN_DELETE File/directory deleted from watched directory (*)
- IN_DELETE_SELF Watched file/directory was itself deleted
- IN_MODIFY File was modified (*)
- IN_MOVE_SELF Watched file/directory was itself moved
- IN_MOVED_FROM File moved out of watched directory (*)
- IN_MOVED_TO File moved into watched directory (*)
- IN_OPEN File was opened (*)
- When monitoring a directory, the events marked with an asterisk (*)
- above can occur for files in the directory, in which case the name
- field in the returned inotify_event structure identifies the name of
- the file within the directory.
- The IN_ALL_EVENTS macro is defined as a bit mask of all of the above
- events. This macro can be used as the mask argument when calling ino-
- tify_add_watch().
- Two additional convenience macros are IN_MOVE, which equates to
- IN_MOVED_FROM|IN_MOVED_TO, and IN_CLOSE which equates to
- IN_CLOSE_WRITE|IN_CLOSE_NOWRITE.
- The following further bits can be specified in mask when calling ino-
- tify_add_watch():
- Bit Description
- IN_DONT_FOLLOW Don't dereference pathname if it is a symbolic link
- IN_MASK_ADD Add (OR) events to watch mask for this pathname if
- it already exists (instead of replacing mask)
- IN_ONESHOT Monitor pathname for one event, then remove from
- watch list
- IN_ONLYDIR Only watch pathname if it is a directory
- The following bits may be set in the mask field returned by read():
- Bit Description
- IN_IGNORED Watch was removed explicitly (inotify_rm_watch())
- or automatically (file was deleted, or
- file system was unmounted)
- IN_ISDIR Subject of this event is a directory
- IN_Q_OVERFLOW Event queue overflowed (wd is -1 for this event)
- IN_UNMOUNT File system containing watched object was unmounted
- /proc interfaces
- The following interfaces can be used to limit the amount of kernel mem-
- ory consumed by inotify:
- /proc/sys/fs/inotify/max_queued_events
- The value in this file is used when an application calls ino-
- tify_init(2) to set an upper limit on the number of events that
- can be queued to the corresponding inotify instance. Events in
- excess of this limit are dropped, but an IN_Q_OVERFLOW event is
- always generated.
- /proc/sys/fs/inotify/max_user_instances
- This specifies an upper limit on the number of inotify instances
- that can be created per real user ID.
- /proc/sys/fs/inotify/max_user_watches
- This specifies a limit on the number of watches that can be
- associated with each inotify instance.
- NOTES
- Inotify file descriptors can be monitored using select(2), poll(2), and
- epoll(7).
- If successive output inotify events produced on the inotify file
- descriptor are identical (same wd, mask, cookie, and name) then they
- are coalesced into a single event.
- The events returned by reading from an inotify file descriptor form an
- ordered queue. Thus, for example, it is guaranteed that when renaming
- from one directory to another, events will be produced in the correct
- order on the inotify file descriptor.
- The FIONREAD ioctl() returns the number of bytes available to read from
- an inotify file descriptor.
- Inotify monitoring of directories is not recursive: to monitor subdi-
- rectories under a directory, additional watches must be created.
- VERSIONS
- Inotify was merged into the 2.6.13 Linux kernel. The required library
- interfaces were added to glibc in version 2.4.
- BUGS
- In kernels before 2.6.16, the IN_ONESHOT mask flag does not work.
- As at glibc 2.4, the definitions for IN_DONT_FOLLOW, IN_MASK_ADD, and
- IN_ONLYDIR are missing from <sys/inotify.h>.
- CONFORMING TO
- The inotify API is Linux specific.
- SEE ALSO
- inotify_add_watch(2), inotify_init(2), inotify_rm_watch(2), read(2),
- stat(2), Documentation/filesystems/inotify.txt.
- Linux 2.6.15 2006-02-07 INOTIFY(7)
|
|
免费注册
发表于 2006-08-26 14:02
发表于 2006-08-28 17:33