谁能帮我写一个脚本，监视目录的

Question

监视一个目录，如果这个目录及其子目录，产生了新文件，调用杀毒软件扫描新文件，如果发现病毒，立即删除这个新文件。

Answer 1

原帖由 flw 于 2006-8-28 17:33 发表

这个方法很土（尽管也许它很管用），

自从 linux 2.4 之后，linux 内核就支持一套监视目录的接口，
楼主可以 man 一下 fcntl，下面是从我的机器上摘录下来的部分：
[code]FCNTL(2)                   Linu ...

>>
>>
>>还真没有用过这个，赞一个！
>>
>>

Answer 2

原帖由 Bayweb 于 2006-8-27 19:49 发表

>>
>>
>>Linux下可以通过比较目录文件的内容是否一样（.文件）实现
>>1.事先将文件列表或者目录文件储存起来（例如文件、程序变量）
>>2.定时获得当前文件信息，进行比较
& ...

这个方法很土（尽管也许它很管用），

自从 linux 2.4 之后，linux 内核就支持一套监视目录的接口，
楼主可以 man 一下 fcntl，下面是从我的机器上摘录下来的部分：

1. FCNTL(2)                   Linux Programmer's Manual                  FCNTL(2)
3. NAME
4.        fcntl - manipulate file descriptor
5. .....<omit>.....
6.    File and directory change notification (dnotify)
7.        F_NOTIFY
8.               (Linux  2.4  onwards)  Provide  notification  when the directory
9.               referred to by fd or any  of  the  files  that  it  contains  is
10.               changed.   The events to be notified are specified in arg, which
11.               is a bit mask specified by ORing together zero or  more  of  the
12.               following bits:
14.               Bit         Description (event in directory)
15.               -------------------------------------------------------------
16.               DN_ACCESS   A file was accessed (read, pread, readv)
17.               DN_MODIFY   A file was modified (write, pwrite,
18.                           writev, truncate, ftruncate)
19.               DN_CREATE   A file was created (open, creat, mknod,
20.                           mkdir, link, symlink, rename)
21.               DN_DELETE   A file was unlinked (unlink, rename to
22.                           another directory, rmdir)
23.               DN_RENAME   A file was renamed within this
24.                           directory (rename)
25.               DN_ATTRIB   The attributes of a file were changed
26.                           (chown, chmod, utime[s])
28.               (In  order  to obtain these definitions, the _GNU_SOURCE feature
29.               test macro must be defined.)
31.               Directory notifications are normally "one-shot", and the  appli-
32.               cation   must  re-register  to  receive  further  notifications.
33.               Alternatively, if DN_MULTISHOT is included in arg, then  notifi-
34.               cation will remain in effect until explicitly removed.
36.               A  series of F_NOTIFY requests is cumulative, with the events in
37.               arg being added to the set already monitored.  To disable  noti-
38.               fication  of all events, make an F_NOTIFY call specifying arg as
39.               0.
41.               Notification occurs via delivery of a signal.  The default  sig-
42.               nal is SIGIO, but this can be changed using the F_SETSIG command
43.               to fcntl().  In the latter case, the signal handler  receives  a
44.               siginfo_t  structure  as its second argument (if the handler was
45.               established using SA_SIGINFO) and the si_fd field of this struc-
46.               ture   contains   the   file   descriptor  which  generated  the
47.               notification (useful when establishing notification on  multiple
48.               directories).
50.               Especially  when using DN_MULTISHOT, a POSIX.1b real time signal
51.               should be used for notification, so that multiple  notifications
52.               can be queued.
54.               NOTE:  New applications should consider using the inotify inter-
55.               face (available since kernel 2.6.13), which provides a  superior
56.               interface  for  obtaining  notifications  of file system events.
57.               See inotify(7).

复制代码
上面把这套机制基本上说清楚了。
另外还提到，自从 2.6.13 之后，kernel 又提供了一套更高级、更方便的接口，下面是它的文档：

1. INOTIFY(7)                 Linux Programmer's Manual                INOTIFY(7)
3. NAME
4.        inotify - monitoring file system events
6. DESCRIPTION
7.        The inotify API provides a mechanism for monitoring file system events.
8.        Inotify can be used to monitor individual files, or to monitor directo-
9.        ries.   When  a  directory is monitored, inotify will return events for
10.        the directory itself, and for files inside the directory.
12.        The following system calls are used with this API: inotify_init(), ino-
13.        tify_add_watch(), inotify_rm_watch(), read(), and close().
15.        inotify_init(2) creates an inotify instance and returns a file descrip-
16.        tor referring to the inotify instance.
18.        inotify_add_watch(2) manipulates the "watch list"  associated  with  an
19.        inotify  instance.  Each item ("watch") in the watch list specifies the
20.        pathname of a file or directory, along with some set of events that the
21.        kernel  should monitor for the file referred to by that pathname.  ino-
22.        tify_add_watch() either creates a new watch item, or modifies an exist-
23.        ing  watch.   Each  watch  has  a unique "watch descriptor", an integer
24.        returned by inotify_add_watch() when the watch is created.
26.        inotify_rm_watch(2) removes an item from an inotify watch list.
28.        When all file descriptors referring to an inotify  instance  have  been
29.        closed, the underlying object and its resources are freed for re-use by
30.        the kernel; all associated watches are automatically freed.
32.        To determine what events have occurred, an  application  read(2)s  from
33.        the  inotify file descriptor.  If no events have so far occurred, then,
34.        assuming a blocking file descriptor, read() will block until  at  least
35.        one event occurs.
37.        Each  successful  read() returns a buffer containing one or more of the
38.        following structures:
40.          struct inotify_event {
41.              int      wd;       /* Watch descriptor */
42.              uint32_t mask;     /* Mask of events */
43.              uint32_t cookie;   /* Unique cookie associating related
44.                                    events (for rename(2)) */
45.              uint32_t len;      /* Size of 'name' field */
46.              char     name[];   /* Optional null-terminated name */
47.          };
49.        wd identifies the watch for which this event occurs.  It is one of  the
50.        watch descriptors returned by a previous call to inotify_add_watch().
52.        mask contains bits that describe the event that occurred (see below).
54.        cookie  is  a  unique  integer that connects related events.  Currently
55.        this is only used for rename events, and allows the resulting  pair  of
56.        IN_MOVE_FROM  and IN_MOVE_TO events to be connected by the application.
58.        The name field is only present when an event is  returned  for  a  file
59.        inside a watched directory; it identifies the file pathname relative to
60.        the watched directory.   This  pathname  is  null-terminated,  and  may
61.        include  further  null  bytes  to  align subsequent reads to a suitable
62.        address boundary.
64.        The len field counts all of the  bytes  in  name,  including  the  null
65.        bytes;  the  length of each inotify_event structure is thus sizeof(ino-
66.        tify_event)+len.
68.    inotify events
69.        The inotify_add_watch(2) mask argument and the mask field of  the  ino-
70.        tify_event  structure returned when read(2)ing an inotify file descrip-
71.        tor are both bit masks identifying inotify events.  The following  bits
72.        can  be  specified  in mask when calling inotify_add_watch() and may be
73.        returned in the mask field returned by read():
75.          Bit                Description
76.          IN_ACCESS          File was accessed (read) (*)
77.          IN_ATTRIB          Metadata changed (permissions, timestamps,
78.                             extended attributes, etc.) (*)
79.          IN_CLOSE_WRITE     File opened for writing was closed (*)
80.          IN_CLOSE_NOWRITE   File not opened for writing was closed (*)
81.          IN_CREATE          File/directory created in watched directory (*)
82.          IN_DELETE          File/directory deleted from watched directory (*)
83.          IN_DELETE_SELF     Watched file/directory was itself deleted
84.          IN_MODIFY          File was modified (*)
85.          IN_MOVE_SELF       Watched file/directory was itself moved
86.          IN_MOVED_FROM      File moved out of watched directory (*)
87.          IN_MOVED_TO        File moved into watched directory (*)
88.          IN_OPEN            File was opened (*)
90.        When monitoring a directory, the events marked  with  an  asterisk  (*)
91.        above  can  occur  for  files  in the directory, in which case the name
92.        field in the returned inotify_event structure identifies  the  name  of
93.        the file within the directory.
95.        The  IN_ALL_EVENTS  macro  is defined as a bit mask of all of the above
96.        events.  This macro can be used as the mask argument when calling  ino-
97.        tify_add_watch().
99.        Two  additional  convenience  macros  are  IN_MOVE,  which  equates  to
100.        IN_MOVED_FROM|IN_MOVED_TO,    and    IN_CLOSE    which    equates    to
101.        IN_CLOSE_WRITE|IN_CLOSE_NOWRITE.
103.        The  following  further bits can be specified in mask when calling ino-
104.        tify_add_watch():
106.          Bit              Description
107.          IN_DONT_FOLLOW   Don't dereference pathname if it is a symbolic link
108.          IN_MASK_ADD      Add (OR) events to watch mask for this pathname if
109.                           it already exists (instead of replacing mask)
110.          IN_ONESHOT       Monitor pathname for one event, then remove from
111.                           watch list
112.          IN_ONLYDIR       Only watch pathname if it is a directory
114.        The following bits may be set in the mask field returned by read():
116.          Bit             Description
117.          IN_IGNORED      Watch was removed explicitly (inotify_rm_watch())
118.                          or automatically (file was deleted, or
119.                          file system was unmounted)
120.          IN_ISDIR        Subject of this event is a directory
121.          IN_Q_OVERFLOW   Event queue overflowed (wd is -1 for this event)
122.          IN_UNMOUNT      File system containing watched object was unmounted
124.    /proc interfaces
125.        The following interfaces can be used to limit the amount of kernel mem-
126.        ory consumed by inotify:
128.        /proc/sys/fs/inotify/max_queued_events
129.               The  value  in  this file is used when an application calls ino-
130.               tify_init(2) to set an upper limit on the number of events  that
131.               can  be queued to the corresponding inotify instance.  Events in
132.               excess of this limit are dropped, but an IN_Q_OVERFLOW event  is
133.               always generated.
135.        /proc/sys/fs/inotify/max_user_instances
136.               This specifies an upper limit on the number of inotify instances
137.               that can be created per real user ID.
139.        /proc/sys/fs/inotify/max_user_watches
140.               This specifies a limit on the number  of  watches  that  can  be
141.               associated with each inotify instance.
143. NOTES
144.        Inotify file descriptors can be monitored using select(2), poll(2), and
145.        epoll(7).
147.        If successive output  inotify  events  produced  on  the  inotify  file
148.        descriptor  are  identical  (same wd, mask, cookie, and name) then they
149.        are coalesced into a single event.
151.        The events returned by reading from an inotify file descriptor form  an
152.        ordered  queue.  Thus, for example, it is guaranteed that when renaming
153.        from one directory to another, events will be produced in  the  correct
154.        order on the inotify file descriptor.
156.        The FIONREAD ioctl() returns the number of bytes available to read from
157.        an inotify file descriptor.
159.        Inotify monitoring of directories is not recursive: to  monitor  subdi-
160.        rectories under a directory, additional watches must be created.
162. VERSIONS
163.        Inotify  was merged into the 2.6.13 Linux kernel.  The required library
164.        interfaces were added to glibc in version 2.4.
166. BUGS
167.        In kernels before 2.6.16, the IN_ONESHOT mask flag does not work.
169.        As at glibc 2.4, the definitions for IN_DONT_FOLLOW,  IN_MASK_ADD,  and
170.        IN_ONLYDIR are missing from <sys/inotify.h>.
172. CONFORMING TO
173.        The inotify API is Linux specific.
175. SEE ALSO
176.        inotify_add_watch(2),  inotify_init(2),  inotify_rm_watch(2),  read(2),
177.        stat(2), Documentation/filesystems/inotify.txt.
179. Linux 2.6.15                      2006-02-07                        INOTIFY(7)

复制代码

Answer 3

原帖由 zhangshoug 于 2006-8-26 14:02 发表
监视一个目录，如果这个目录及其子目录，产生了新文件，调用杀毒软件扫描新文件，如果发现病毒，立即删除这个新文件。

>>
>>
>>Linux下可以通过比较目录文件的内容是否一样（.文件）实现
>>1.事先将文件列表或者目录文件储存起来（例如文件、程序变量）
>>2.定时获得当前文件信息，进行比较
>>如果只是靠脚本来做到，bash会比较麻烦；建议选用tcl之类的脚本
>>
>>