-
Notifications
You must be signed in to change notification settings - Fork 225
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
What happens to watched directories when they are renamed? #165
Comments
What platform is this? |
But generally:
|
This would be Linux 4.18. I assumed notify still holds an fd to the directory and would thus keep watching it even if it moves. So generally I can assume that when a directory is being watched and then moved, it is not longer being watched and I do not need to undertake any measures to prevent it from being watched? The only thing I do need to do is to watch out for directories that are being moved into locations that I would like to watch? |
So, on Linux, inotify only takes paths as inputs. The kernel does the holding and monitoring, we don't keep FDs ourselves. Other kernel APIs take FDs (like fanotify), but are impractical (such as requiring root and not supporting all events) and also not implemented here. |
If it's moved out of all watched subtrees, yes. If it's moved between watched subtrees, we watch for that and would add a watch on the "new" path.
Correct, but also you might not get to know where a directory moved to, because if it moves outside the inotify-watched subtrees, the destination event won't get emitted. |
When a directory is moved back into it's original place, it will not automatically be watched by inotify again? (i.e. moving a directory I placed a |
By inotify, no. But we catch directory creation within the events we get and add watches for them. (Said events will only give us paths within the subtrees we watch, so it doesn't "escape" the watch root, so to speak.) |
And I mispoke when I said "Notably, notify will not be watching the new path automatically.". I should have added the caveat "if it's out of our purview". Notify does add watches for directories moved or created into our purview. |
I think there might be a misunderstanding. What I mean is: let (tx, rx) = channel();
let mut watcher = watcher(tx, Duration::from_secs(2)).unwrap();
watcher.watch(".", RecursiveMode::NonRecursive); // Watch the main directory for new folders we would like to watch
watcher.watch("templates", RecursiveMode::Recursive);
loop {
match rx.recv() {
Ok(event) => {
match &event {
Create(path) |
Write(path) |
Rename(old_path, new_path) => {
// First situation:
// 1. "templates" directory is renamed to "foo.bar"
// 2. I receive the event here, but what is the state of `watcher` afterwards?
//
// Second situation:
// 1. "foo.bar" directory is renamed to "templates"
// 2. I receive the event here, but what is the state of `watcher` afterwards? Will it automatically watch "templates" recursively again?
}}}} From https://github.com/passcod/notify/blob/master/src/inotify.rs#L232-L270 I gather that for all directories, including those I called |
Yes. The caveats and confusion above is because of the two different watch contexts. In all-recursive contexts, the watches would be re-added and everything would work "as expected". Here, the top context is non-recursive, and rename events are only tracked "from above", so notify doesn't re-add watches. This is possibly a missing feature but I'll have to think more about it. In more detail: Because you're watching both from without and within, if the move event is from the watch on The sequence goes like this:
|
Thank you very much for the detailed explanation! I am in the process of writing an opportunistic watcher, which would be able to |
This summarises the knowledge gathered from notify-rs#165 (comment) Closes: notify-rs#165
This summarises the knowledge gathered from notify-rs#165 (comment) Closes: notify-rs#165
This summarises the knowledge gathered from notify-rs#165 (comment) Closes: notify-rs#165
This summarises the knowledge gathered from notify-rs#165 (comment) Closes: notify-rs#165
This summarises the knowledge gathered from notify-rs#165 (comment) Closes: notify-rs#165
Would the |
Current version is feature-frozen ("maintained, not developed") and the next version will have significantly different architecture, so not directly, but I'll keep it in mind! |
Fixes these messages: warning: this URL is not a hyperlink --> crates/arti/src/watch_cfg.rs:115:5 | 115 | /// notify-rs/notify#165 and | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: use an automatic link instead: `<https://github.com/notify-rs/notify/issues/165>` | = note: `#[warn(rustdoc::bare_urls)]` on by default = note: bare URLs are not automatically turned into clickable links warning: this URL is not a hyperlink --> crates/arti/src/watch_cfg.rs:116:5 | 116 | /// notify-rs/notify#166 . | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: use an automatic link instead: `<https://github.com/notify-rs/notify/pull/166>` | = note: bare URLs are not automatically turned into clickable links
I am watching a directory (recursively) and also its parent (non-recursively). When I detect a
Rename(old, new)
event, I tried tounwatch()
theold
path, but that produced an error (old path is not being watched). The same happened when I tried tounwatch()
thenew
path. Now my question is: How come? What happens to watched directories when they are renamed?The text was updated successfully, but these errors were encountered: