Skip to content
This repository has been archived by the owner on Nov 6, 2018. It is now read-only.

Revisit how physical file watcher handles events #189

Closed
NTaylorMullen opened this issue May 10, 2016 · 2 comments
Closed

Revisit how physical file watcher handles events #189

NTaylorMullen opened this issue May 10, 2016 · 2 comments
Labels
Milestone

Comments

@NTaylorMullen
Copy link
Contributor

We did a quick fix for #187 for RC2 but we should revisit the solution for RTM. Aka, it's bad that we're swallowing exceptions and should investigate other alternatives.

@muratg muratg added this to the 1.0.0 milestone May 11, 2016
@muratg muratg modified the milestones: 1.0.1, 1.0.0 May 26, 2016
@muratg muratg modified the milestones: 1.2.0, 1.1.0 Sep 23, 2016
@muratg muratg modified the milestones: 1.2.0, 2.0.0 Jan 12, 2017
@muratg muratg modified the milestones: 2.0.0-preview1, 2.0.0-preview2 Apr 21, 2017
@muratg muratg modified the milestones: 2.0.0-preview3, 2.0.0-preview2 May 25, 2017
@natemcmaster
Copy link
Contributor

@muratg I recommend we close as wont-fix. The result of this bug is that a file watch token may not always fire for renamed events when the rename caused the directory structure to change permissions or exceed the MAX_PATH length.

I've looked at the changes made in #187, and there aren't good alternatives. In this specific case, it is the System.IO API that is throws when there is an issue traversing the directory structure. There aren't any non-throwing System.IO apis we can use to achieve the same result.

@muratg muratg added the wontfix label Jun 12, 2017
@muratg
Copy link

muratg commented Jun 12, 2017

👍

@muratg muratg closed this as completed Jun 12, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants