No error when stopping watching a non watched file#455
Closed
MidasLamb wants to merge 1 commit intofsnotify:mainfrom
Closed
No error when stopping watching a non watched file#455MidasLamb wants to merge 1 commit intofsnotify:mainfrom
MidasLamb wants to merge 1 commit intofsnotify:mainfrom
Conversation
Currently, when a non-watched item is requested to be removed from a watch, an error is returned. However, the post-condition of removing it is: "This file/dir should not be watched anymore", which is the case also when the item wasn't being watched in the first place. Rather than returning an error. Return nil and skip a part of the work.
Member
|
If this Remove function returns a wrapped error for |
Author
That could also be a possibility. I'm not that experienced in go so I don't know what would be the most idiomatic way. |
Member
|
I prefer to add and return it in inotify.go, kqueue.go, windows.go any thought? @nathany @shogo82148 |
Contributor
|
@mattn a new error sounds good to me |
arp242
pushed a commit
that referenced
this pull request
Jul 21, 2022
The errors returned by the various implementations of the watcher are all different which makes handling them difficult. This PR follows the suggestion in: #455 (comment) by @mattn to create a common error which is wrapped by the implementations. Replaces: #455 Signed-off-by: Andrew Thornton <art27@cantab.net>
Member
|
I agree that outright removing the error is not a good solution; I opened #460 to return a specific error that can be tested for, which should address the issue better. |
arp242
added a commit
that referenced
this pull request
Jul 21, 2022
The errors returned by the various implementations of the watcher are all different which makes handling them difficult. This PR follows the suggestion in: #455 (comment) by @mattn to create a common error which is wrapped by the implementations. Replaces: #455 Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: Andrew Thornton <art27@cantab.net>
5 tasks
shogo82148
pushed a commit
to shogo82148/fsnotify
that referenced
this pull request
Mar 6, 2024
port of fsnotify/fsnotify#460 The errors returned by the various implementations of the watcher are all different which makes handling them difficult. This PR follows the suggestion in: fsnotify/fsnotify#455 (comment) by @mattn to create a common error which is wrapped by the implementations.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this pull request do?
Currently, when a non-watched item is requested to be removed from a
watch, an error is returned.
However, the post-condition of removing it is: "This file/dir should not
be watched anymore", which is the case also when the item wasn't being
watched in the first place.
Rather than returning an error. Return nil and skip a part of the work.
Where should the reviewer start?
inotify.go, the Remove function definition.
How should this be manually tested?
We've noticed this because this lib is being used in promtail and it was logging errors because of this.