1

man inotifywait:

delete_self A watched file or directory was deleted. After this event the file or directory is no longer being watched. Note that this event can occur even if it is not explicitly being listened for.

unmount The filesystem on which a watched file or directory resides was unmounted. After this event the file or directory is no longer being watched. Note that this event can occur even if it is not explicitly being listened to.

How to understand mean of "that this event can occur even if it is not explicitly being listened" on that manual page?

https://manpages.debian.org/stretch/inotify-tools/inotifywait.1.en.html

Improve this question

2 Answers 2

Reset to default
3

When you ask inotifywait to wait for an event (i.e. not in --monitor mode), and you specify one or more event types (with the --event option), it normally doesn't exit until that particular event occurs. For example:

$ touch foo $ inotifywait -e access foo Setting up watches. Watches established. $ echo >>foo $ cat foo foo ACCESS $ $ echo $? 0 $

(The two columns represent separate terminals, with blank lines inserted to make the events come out in chronological order.) Here, after the watch on foo is established, there's a MODIFY event, but since the event filter on the inotifywait doesn't include MODIFY, nothing happens. The inotifywait command only returns later when an ACCESS event happens.

Now suppose the file is deleted while it's being watched for access.

 $ inotifywait -e access foo Setting up watches. Watches established. $ rm foo $ $ echo $? 1 $

Removing foo triggers a DELETE_SELF event. The inotifywait command sees this event. It doesn't print it, because it was told to only report ACCESS events. But inotifywait exits: it did count the event even though it wasn't in the filter. The command exits with status 1 to indicate that “an event occurred which was not being listened for” (and wasn't ignored as most non-watched events are).

Improve this answer
3
  • Thank you. but I tested your example that echo >>foo also triggers a ACCESS event ? Commented Nov 8, 2017 at 4:57
  • @illiteracy It shouldn't, and I can't reproduce this. Commented Nov 8, 2017 at 9:58
  • I just try guess for this,maybe this is something of shell(as such some shell option or other shell thing)?my shell :GNU bash, version 4.4.12(1)-release (i686-pc-linux-gnu),I'm not know if any shell option maybe is about to this. Commented Nov 9, 2017 at 14:53
1

It means you can get these events even if you used the -e option and didn't specify them. For instance, if you use

inotifywait -e modify filename

and the file is deleted, you'll get a delete_self event, even though you only asked for modify events.

This means you need to check the event type in the output, even if you only requested a specific event.

Improve this answer
2
  • Thank you ,but really I need check output ? non-specified event seem is hide on output as Gilles said and I tested that. Commented Nov 8, 2017 at 5:02
  • If you don't check the output, you have to check the exit status, as he pointed out. Commented Nov 8, 2017 at 5:35

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.