Ability to unwatch a file.

[mark-e-hoffman]

Hi, I'm using your library to tail/watch multiple log files in a directory and its child directories.
Everything is working well, except that it appears that the library is not closing its file handle on the watched file whenever the process actually writing to the log file closes it.

I see that if a file is removed it will be unwatched but I only want it to be unwatched when it's Closed.
My code is also using notify so I can have a finer grain control of file events. Whenever I see a Close EventKind on a file that I'm tailing, I want to be able to "unwatch" it. There is an unwatch function on the MuxLines but it's not public.

Thanks

[jmagnuson]

Exposing the unwatch API would be a nice addition! I think the main question would be, does it require the exact Path that was internally canonicalized, or does it internally canonicalize and hope for a match.

Removing on close is also interesting, could you elaborate on the use-case? Currently, file closure causes the file watch to be put into a pending state, so the two cases would need to coexist somehow.

[mark-e-hoffman]

Hi, thanks for responding. I actually found a work around were I kept my own monitoring of notify events and switched from your library to a very simple one that just fetches the last line of the file on demand. I trigger this on each modify event for the file. My usecase it to monitor log files in a specific directory of child directories underneath that root. I only monitor files that match a configured regex. Whenever I capture a Close event I stop monitoring the file. This works for me since I know that the file won't be opened again for writing. I understand why you might want to hang on to the Path incase the file is reopened. This really isn't my usecase. Thanks again for replying so quickly.

…

On Sat, Dec 17, 2022 at 3:39 PM Jon Magnuson ***@***.***> wrote: Exposing the unwatch API would be a nice addition! I think the main question would be, does it require the exact Path that was internally canonicalized, or does it internally canonicalize and hope for a match. Removing on close is also interesting, could you elaborate on the use-case? Currently, file closure causes the file watch to be put into a pending state, so the two cases would need to coexist somehow. — Reply to this email directly, view it on GitHub <#63 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMZ4PLWRKU4K26FJLXUDPDWNYQIRANCNFSM6AAAAAAS6TQ56Y> . You are receiving this because you authored the thread.Message ID: ***@***.***>