Skip to content
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

Merge upstream #112

Open
wants to merge 13 commits into
base: master
Choose a base branch
from
Open

Merge upstream #112

wants to merge 13 commits into from

Conversation

2shortplanks
Copy link

@2shortplanks 2shortplanks commented Aug 23, 2021

This brings in work from pull request from our local fork, passed back upstream.

Since nothing else has been merged upstream I'm not expecting this to either, but I'm doing this so that people can at least see what changes we've made.

tul and others added 13 commits January 10, 2020 17:44
ScanNow() causes the file watch loop to run once, and ensures
all events have been posted before returning. It allows the
caller to "synchronize" with the pending watcher events, so
is useful for batch updating after it is known file events
have probably occurred.
On some file systems, multiple changes to the same file within
the file system's mod time resolution would be missed. This
issue can be ameliorated by triggering `Write` events if a
size change is detected, even if no corresponding mod time
change occurs.

Changes to the file content without a change to the size or
mod time will still go unnoticed.
sometimes when a file/dir which is being watched is
deleted a panic will occur. This appears to be because
the is an assumption that if an error returns true for
`IsNotExist()` that it should be castable to `os.PathError`,
but this evidently is not always the case, causing a panic.
fix panic when file/dir is deleted
Watcher now emits `Write` event for size only change
When we close while waiting for the next periodic re-roll or ScanNow we
previously would allow the loop to execute one last time, start a rescan,
and then exit the Start() function when we got a <-w.close.  However,
when this happens and there's a changed files there's a 50% for each file
we'll choose to process the <-evt file event first before the <-w.close!
This is a huge problem if it's no longer safe to do so.

This change simply exits the Start function (safely, closing all the
channels as before) as soon as we receive a <-w.close
@2shortplanks 2shortplanks changed the title Fix race condtion with closin Merge upstream Aug 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants