CreateKind | RemoveKind | ModifyKind seem to always be Any most of the time?

[oOBoomberOo]

System details

• OS/Platform name and version: Windows 10
• Rust version (if building from source): 1.46.0
• Notify version (or commit hash if building from git): 5.0.0-pre.3

• Filesystem type and options: NTFS

What you did (as detailed as you can)

I have a basic file watcher function which watch for any event from some path recursively:

let mut source_watcher = immediate_watcher(move |res| match res {
	Ok(event) => {
		let event: Event = event;
		log::info!("{:#?}", event);
	}
	Err(e) => log::error!("{}", e),
})?;

source_watcher.watch(&path, RecursiveMode::Recursive)?;
// ...

What you expected

The log message will print a helpful message of what exactly happened with the file/folder under that path.

What happened

The log message will almost always print an Any variant of CreateKind, RemoveKind, and ModifyKind. Only when I try renaming some file that it manage to print the ModifyKind::Name variant.

Wouldn't this be quite useless for a more complex situation where you need to know what exactly happened to the file/folder?

[JohnTitor]

Yes, the relevant code is:

notify/src/windows.rs

Lines 364 to 386 in b07225e

	match (*cur_entry).Action {
	winnt::FILE_ACTION_RENAMED_NEW_NAME => {
	let kind = EventKind::Modify(ModifyKind::Name(RenameMode::To));
	let ev = newe.set_kind(kind);
	event_fn(Ok(ev));
	}
	winnt::FILE_ACTION_ADDED => {
	let kind = EventKind::Create(CreateKind::Any);
	let ev = newe.set_kind(kind);
	event_fn(Ok(ev));
	}
	winnt::FILE_ACTION_REMOVED => {
	let kind = EventKind::Remove(RemoveKind::Any);
	let ev = newe.set_kind(kind);
	event_fn(Ok(ev));
	}
	winnt::FILE_ACTION_MODIFIED => {
	let kind = EventKind::Modify(ModifyKind::Any);
	let ev = newe.set_kind(kind);
	event_fn(Ok(ev));
	}
	_ => (),
	};

Definitely we should coordinate it but it needs the information whether it's a dir, file, or unknown.

[oOBoomberOo]

In that case, should I close it under the reason that it's working as intended?

[JohnTitor]

No, I'd like to take this as an improvement. I haven't found any flags from ReadDirectoryChangesW, but we can use is_dir/is_file from std::fs::metadata as we have a path of an item.

[rawnly]

Any improvement on this?

[0xpr03]

I'm not sure how worth the overhead is for that. If I understand this right we'd have to store a hashmap for all file descriptors which tells us whether its a folder or a file / perform a path lookup (IO). Currently our windows backend does not require us to keep track of anything like that, in contrast to linux where we have to work through all files to watch.

Thus I'd at least make it somehow optional. (We can do so via the new Config flags, which allows the debouncer-mini to just set this to "no")