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
Comments
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. |
related #170 |
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
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
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
When renaming/moving a watched directory that is not inside a watched directory, fsnotify informs of the renaming, but:
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.
The text was updated successfully, but these errors were encountered: