Filenames without path not handled on Windows

[JoannesJ]

Supplying watch() with just a filename and no path will result in a "parent directory could not be opened" error.

This is because Path.parent() doesn't return the actual path to the parent directory, but rather the original path minus the last entry, resulting in an empty string when given just a filename.

[passcod]

What would be the behaviour you're looking for here? Watch the current directory?

[JoannesJ]

Yeah.
I would expect that there would be no difference between watching a file passing the path "project/file.txt" and watching the same file passing "file.txt" with the working directory being "project".

The need for watching the parent directory on Windows is an implementation detail that shouldn't effect behavior.

I don't have access to any of the other OS', but I'm betting that this behavior is inconsistent across.

[passcod]

I think we could resolve the path to absolute before passing it to the backend. What do you think @Hessijames?

[dfaust]

Will be fixed in the next release, until then you can use:
env::current_dir().unwrap().join("my_file")
to build an absolute path.

[JoannesJ]

Maybe path.canonicalize() would be better. I think your current patch would fail on network files, i.e. "//network-computer/shared-folder/file.txt".

[dfaust]

Good point. I wasn't able to test it, but using canonicalize() seems better anyway.

[JoannesJ]

Btw, I'm receiving 2 WRITE events when saving a file. Is this expected?

[passcod]

Yes, this is known. There are plans to provide debounced events for that reason, see #63.

[dfaust]

As mentioned in issue #95, canonicalize() uses returns \?\ style paths. That can be confusing when a "normal" path was passed to watch(). So I reverted the "canonicalize" commit and went back to using env::current_dir(). This time I tested it with network shares and it does work. So I can't see any problems.
In case I'm wrong, please let me know.