Fix a silent fail if path is a file #1034 (Windows only).

[TobiasRzepka]

CreateFileW can only track directories, not files. In case of files, start tracking the directory and filter out files which are not tracked.

Fixes #1034.

[TobiasRzepka]

Use cache for "is file". Rebased and squashed.

[TobiasRzepka]

@BoboTiG : Anything else what I missed?

[BoboTiG]

Thanks for your work @TobiasRzepka, it's taking time because I am not sure about the implementation. I am a little bit concerned about potential performances impact. I might come again later with some free time, though.

[darabos]

Thanks for this! I hit the same issue — I tried to watch a single file, saw Watchdog stop after the first change due to DirDeletedEvent, and spent an hour debugging it. I'd be very happy to see this merged!

I am a little bit concerned about potential performances impact.

Maybe an if self.watch.path in self._watched_files would be more straightforward than the exception catching mechanism? Or even a self.is_single_file flag, which would make sure the new code only affects the case where a single file is watched.

Or if you're unsure about this, how about at least adding an assertion that the watched path is a directory? I'd have preferred an error to weird behavior.

[BoboTiG]

The idea of a self.is_single_file attribute (or whatever name) seems more appealing to me.

Also, please add a line in the changelog.

[TobiasRzepka]

Maybe an if self.watch.path in self._watched_files would be more straightforward

From performance view it's worse: You have to do a lookup if it's in the dict and handle it gracefully. Till here it's very similar. But when you have a hit, you do it again, to query the value. So you do the access twice when using the if statement.

Or even a self.is_single_file flag

Same as above: Python relies on dictionary-lookups. So the lookup of the attribute is_single_file takes only little less time as the whole lookup for the value. Besides, where should the attribute assigned to?

[TobiasRzepka]

Double buffering as in #1152 is okay, but the implementation isn't. There was always a 2 s timeout waiting for another incoming event till the last event will be processed. With get() the already received events are returned.

[TobiasRzepka]

eric-ide got mad when there is no timeout to wait until events are delivered. But it's done by a time.sleep to avoid endless waiting times if another events (periodically) occur while waiting.