On Fri 04-04-14 09:35:50, Michael Kerrisk (man-pages) wrote: > On 04/03/2014 10:52 PM, Jan Kara wrote: > > On Thu 03-04-14 08:34:44, Michael Kerrisk (man-pages) wrote: > >> Limitations and caveats > >> The inotify API provides no information about the user or process > >> that triggered the inotify event. In particular, there is no > >> easy way for a process that is monitoring events via inotify to > >> distinguish events that it triggers itself from those that are > >> triggered by other processes. > >> > >> The inotify API identifies affected files by filename. However, > >> by the time an application processes an inotify event, the file‐ > >> name may already have been deleted or renamed. > >> > >> The inotify API identifies events via watch descriptors. It is > >> the application's responsibility to cache a mapping (if one is > >> needed) between watch descriptors and pathnames. Be aware that > >> directory renamings may affect multiple cached pathnames. > >> > >> Inotify monitoring of directories is not recursive: to monitor > >> subdirectories under a directory, additional watches must be cre‐ > >> ated. This can take a significant amount time for large direc‐ > >> tory trees. > > And also there's a problem with the limit on the number of watches a user > > can have. > > What is the problem exactly (given that the limit is configurable)? Well, if you want to watch the whole home directory and you have a large one, you may run into that limit. Sure you can ask sysadmin to raise the limit but it's a bit anoying. > >> If monitoring an entire directory subtree, and a new subdirectory > >> is created in that tree or an existing directory is renamed into > >> that tree, be aware that by the time you create a watch for the > >> new subdirectory, new files (and subdirectories) may already > >> exist inside the subdirectory. Therefore, you may want to scan > >> the contents of the subdirectory immediately after adding the > >> watch (and, if desired, recursively add watches for any subdirec‐ > >> tories that it contains). > >> > >> Note that the event queue can overflow. In this case, events are > >> lost. Robust applications should handle the possibility of lost > >> events gracefully. For example, it may be necessary to rebuild > >> part or all of the application cache. (One simple, but possibly > >> expensive, approach is to close the inotify file descriptor, > >> empty the cache, create a new inotify file descriptor, and then > >> re-create watches and cache entries for the objects to be moni‐ > >> tored.) > >> > >> Dealing with rename() events > >> The IN_MOVED_FROM and IN_MOVED_TO events that are generated by > >> rename(2) are usually available as consecutive events when read‐ > >> ing from the inotify file descriptor. However, this is not guar‐ > >> anteed. If multiple processes are triggering events for moni‐ > >> tored objects, then (on rare occasions) an arbitrary number of > >> other events may appear between the IN_MOVED_FROM and IN_MOVED_TO > >> events. > >> > >> Matching up the IN_MOVED_FROM and IN_MOVED_TO event pair gener‐ > >> ated by rename(2) is thus inherently racy. (Don't forget that if > >> an object is renamed outside of a monitored directory, there may > >> not even be an IN_MOVED_TO event.) Heuristic approaches (e.g., > >> assume the events are always consecutive) can be used to ensure a > >> match in most cases, but will inevitably miss some cases, causing > >> the application to perceive the IN_MOVED_FROM and IN_MOVED_TO > >> events as being unrelated. If watch descriptors are destroyed > >> and re-created as a result, then those watch descriptors will be > >> inconsistent with the watch descriptors in any pending events. > >> (Re-creating the inotify file descriptor and rebuilding the cache > >> may be useful to deal with this scenario.) > > Well, but there's 'cookie' value meant exactly for matching up > > IN_MOVED_FROM and IN_MOVED_TO events. And 'cookie' is guaranteed to be > > unique at least within the inotify instance (in fact currently it is unique > > within the whole system but I don't think we want to give that promise). > > Yes, that's already assumed by my discussion above (its described elsewhere > in the page). But your comment makes me think I should add a few words to > remind the reader of that fact. I'll do that. Yes, that would be good. > But, the point is that even with the cookie, matching the events is > nontrivial, since: > > * There may not even be an IN_MOVED_FROM event > * There may be an arbitrary number of other events in between the > IN_MOVED_FROM and the IN_MOVED_TO. > > Therefore, one has to use heuristic approaches such as "allow at least > N millisconds" or "check the next N events" to see if there is an > IN_MOVED_FROM that matches the IN_MOVED_TO. I can't see any way around > that being inherently racy. (It's unfortunate that the kernel can't > provide a guarantee that the two events are always consecutive, since > that would simply user space's life considerably.) Yeah, it's unpleasant but doing that would be quite costly/complex at the kernel side. And the race would in the worst case lead to application thinking there's been file moved outside of watched area & a file moved somewhere else inside the watched area. So the application will have to possibly inspect that file. That doesn't seem too bad. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
