-
Notifications
You must be signed in to change notification settings - Fork 52
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
Do not force absolute Paths #49
Comments
Thanks for reporting the issue. A PR would be appreciated. |
I have a tentative PR that works with the provided test case, by stripping the mount points from the paths before adding them to the monitoring list: #58 |
So the problem identified here is that EventStream is mixing For the typical users of this package, is there any reason to prefer If the goal of this package is future adoption in fsnotify/fsnotify then simplifying the primary codepath would be beneficial, right? |
absolutely agree that there's probably a need to revisit the public API.
I'm not familiar enough with the project to offer significant input right
now but am happy to. help with whatever implementation is decided upon.
…On Sat, Jan 22, 2022, 23:27 Jeremy Jay ***@***.***> wrote:
So the problem identified here is that EventStream is mixing
FSEventStreamCreate and FSEventStreamCreateRelativeToDevice which each
have different input requirements, and each provide different sources for
event IDs under the hood. The selection of which stream type is done
magically depending on the value of EventStream.Device
For the typical users of this package, is there any reason to prefer
FSEventStreamCreateRelativeToDevice and add all the complexity of PR #58
<#58> ?
Would it make more sense to split the advanced functionality into a
DeviceEventStream interface that makes the behavior explicit? This would
still allow for persistent notifications but wouldn't introduce more
surface area for bugs in the most common use-case.
If the goal of this package is future adoption in fsnotify/fsnotify then
simplifying the primary codepath would be beneficial, right?
—
Reply to this email directly, view it on GitHub
<#49 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHCVHSAF2RJQKQYXD2JJRDUXMOKLANCNFSM5AQMFFAQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Simple is good. |
fsevents @ 1055680
Which version of macOS are you using?
Please describe the issue that occurred.
FSEvents
api supports two different ways of starting an event stream:FSEventStreamCreateRelativeToDevice
which is expecting paths to be relative to the mount point of the device. This is called theper-disk
event stream in the docs. Theexample/main.go
uses this approach since it uses a non-zero device id. See the documentation here specifically about parampathsToWatchRelativeToDevice
FSEventStreamCreate
which is expecting absolute paths. This is the "per-host" event stream constructor.fsevents
uses this approach if theDevice
in theEventStream
struct is zero. While the docs are ambiguous, on my system, the "per-host" approach only works with absolute paths.However,
wrap.go/createPaths()
transforms all paths in anEventStream
struct to absolute paths atfsevents/wrap.go
Lines 154 to 158 in f721bd2
This prevents using the "per-disk" mode for all volumes except the root volume at
/
.Are you able to reproduce the issue? Please provide steps to reproduce and a code sample if possible.
Yes.
/Volumes/fsevents-repo
(the only change)go run ./example/main.go
touch /Volumes/fsevents-repo/testfile
and observe there is no event reports.and repeat the steps above.
PR coming shortly.
The text was updated successfully, but these errors were encountered: