Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem when moving watched directory with inotify #172

Closed
chmike opened this issue Sep 29, 2016 · 2 comments · Fixed by #518
Closed

Problem when moving watched directory with inotify #172

chmike opened this issue Sep 29, 2016 · 2 comments · Fixed by #518

Comments

@chmike
Copy link

chmike commented Sep 29, 2016

When renaming/moving a watched directory that is not inside a watched directory, fsnotify informs of the renaming, but:

  1. doesn't update the name stored internally
  2. keeps tracking changes inside the directory
  3. report names starting with the old name for changes inside it
  4. attempt to remove the watch will fail wit an error

This is deduced from reading the code and testings with inotify. I didn't verify if this happens and how fsnotify would precisely behave (e.g 4). I'm confident that this is the case.

The reason is due to inotify not returning the new name of the watched directory (IN_MOVE_SELF). If the watched directory is inside a watched directory than the new name may be obtained, but this needs some smart operation. If that watched directory is moved out of the watched directory, it is still watched, bu the new name is unknown and the watcher can't be removed.

One possible fix is to automatically unwatch moved/renamed directories that aren't inside a watched directory. Watched directories inside another watched directories should be unwatched only when moved out of the enclosing watched directory. This is required because it is not possible to know their new name.

It is yet unclear if it is possible to track directory moves from one watched directory to another watched directory (could be a subdirectory ) I need to do further tests.

@chmike
Copy link
Author

chmike commented Sep 30, 2016

If fact point 4 is not correct. It is possible to remove the watch but by using the name used to register the directory.

The problem is due to a limitation of inotify.

One of the consequences of a rename/move of a watched dir is that the returned path is invalid. So you may be informed of modifications inside the directory, but you wouldn't be able to access the files to get the stats for instance because the path is wrong. It requires more work to properly keep track of subdirectory moves.

@nathany nathany added the linux label Oct 1, 2016
@nathany
Copy link
Contributor

nathany commented Oct 1, 2016

related #170

@arp242 arp242 added the bug label Jul 29, 2022
arp242 added a commit that referenced this issue Oct 13, 2022
Renaming a watched path is problematic; on inotify we just get a
IN_MOVED_SELF event with the old filename and that's it; no more events
for you! So if you do:

	watch one
	mv    one two
	cat   asd >two

You still continue to get events for the file "one", even though it's
now named "two" (the file descriptor doesn't care about the rename).
There is no way we can know the new event as far as I can tell,
inotifywait(1) also behaves like this. So instead of continuing in a
semi-broken state just remove the watcher, like we do for deletes.

On kqueue and FEN the situation is similar, and we actually already
removed watchers on renames.

On Windows this all works nicely; the watch is preserved and the
filename is updated. I decided to keep this as-is for now, even though
it's inconsistent. We actually fixed the Windows behaviour for the 1.6.0
release in #370 , so people do seem to care about it and use it, and
experience with the symlink change in 1.5.0 shows it's better to keep
inconsistent behaviour rather than change it. Fixing this up is
something for a v2.

Fixes #172
Fixes #503
arp242 added a commit that referenced this issue Oct 13, 2022
Renaming a watched path is problematic; on inotify we just get a
IN_MOVED_SELF event with the old filename and that's it; no more events
for you! So if you do:

	watch one
	mv    one two
	cat   asd >two

You still continue to get events for the file "one", even though it's
now named "two" (the file descriptor doesn't care about the rename).
There is no way we can know the new event as far as I can tell,
inotifywait(1) also behaves like this. So instead of continuing in a
semi-broken state just remove the watcher, like we do for deletes.

On kqueue and FEN the situation is similar, and we actually already
removed watchers on renames.

On Windows this all works nicely; the watch is preserved and the
filename is updated. I decided to keep this as-is for now, even though
it's inconsistent. We actually fixed the Windows behaviour for the 1.6.0
release in #370 , so people do seem to care about it and use it, and
experience with the symlink change in 1.5.0 shows it's better to keep
inconsistent behaviour rather than change it. Fixing this up is
something for a v2.

Fixes #172
Fixes #503
arp242 added a commit that referenced this issue Oct 14, 2022
Renaming a watched path is problematic; on inotify we just get a
IN_MOVED_SELF event with the old filename and that's it; no more events
for you! So if you do:

	watch one
	mv    one two
	cat   asd >two

You still continue to get events for the file "one", even though it's
now named "two" (the file descriptor doesn't care about the rename).
There is no way we can know the new event as far as I can tell,
inotifywait(1) also behaves like this. So instead of continuing in a
semi-broken state just remove the watcher, like we do for deletes.

On kqueue and FEN the situation is similar, and we actually already
removed watchers on renames.

On Windows this all works nicely; the watch is preserved and the
filename is updated. I decided to keep this as-is for now, even though
it's inconsistent. We actually fixed the Windows behaviour for the 1.6.0
release in #370 , so people do seem to care about it and use it, and
experience with the symlink change in 1.5.0 shows it's better to keep
inconsistent behaviour rather than change it. Fixing this up is
something for a v2.

Fixes #172
Fixes #503
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants