-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add capability to ignore paths #3
Conversation
…akes the path as argument and returns a bool
Thanks for your work, but could you first propose/discuss it upstream? I'm gonna leave this PR open and see how the discussion goes. |
As it is a very syncthing-inotify centered approach (I just needed it to get it running correctly on my own system) I thought I propose it on your fork. I wrote a comment on rjeczalik#79 , lets see what the reaction is. |
I now separated the ignoreTest specification from the Watch function. Thus there is no change in how to use the Watch function and everything remains just as it was before. Ignoring is enabled by calling SetIgnoreTest with the desired function that determines which paths are ignored. |
As there is no reaction whatever (not even a "not interested") to this upstream it seems to be up to you what to do. I just want to repeat: My already incorporated PR syncthing/syncthing-inotify#101 is incorrect (suggesting everything is working while it is not) without the changes proposed here. |
@plouj any comments? |
My suggestion is to rename the function to explain what it does more Another software design comment: this is adding a global function and On Fri, Apr 29, 2016 at 1:20 PM, Zillode notifications@github.com wrote:
|
As far as I interpreted the code it should be the former: It does not install watches if the path is ignored (i.e. the introduced function returns true) and just continues installing watches. I will adapt the naming as proposed (probably by Sunday). On your second note: I think I get the point (remember: I don't have any real software design training). My approach was just to implement what I need for syncthing-inotify to work with files that it has no read permissions on if those are ignored and at the same time make this change in the notify package optional, such that everything works as before if one does not use it. So I just tried to minimally change the code. I could try to create a class/struct/whatever is the appropriate object in golang, but it is likely that it will still not be good software design due to my lack of knowledge. I don't know if it is worth the time, also considering @plouj is working on a integration of realtime-notificatoin into syncthing, where this will anyway be done differently (? I do not know the approach there). |
Ok. The second comment was more of a suggestion for future improvement, not As far as I interpreted the code it should be the former: It does not On your second note: I think I get the point (remember: I don't have any — |
I looked at my changes again and I a lot of question marks popped up in my mind (it might be my implementation is completely erroneous and just worked by sheer luck):
I hope what I wrote is understandable and someone with actual go knowledge can bring me up to speed. |
It would be cleaner to pass in an 'initialized' function to the top level |
@Zillode I think this is what I did for the updated PR rjeczalik#107 except that I did want to keep backwards compatibility and go has no optional arguments, so I added a new function which is basically I am pretty certain now that my presently in use implementation is based on a race condition that just luckily works out in the correct way... |
The reason for this PR is that currently installing watches recursively on a directory is aborted when any error is encountered. This PR adds the possibility to ignore errors based on their path. To achieve this a function that determines whether a path should be ignored or not has to be passed as argument to the Watch function. This function has to accepts a path as a string as argument and returns a bool (true for should be ignored).
Possible caveats: