migrate to using FFI and consolidate under the Guard/Listen banner

[ttilley]

It's somewhat awkward to completely outline a plan for your own library in a comment under somebody else's, but apparently that's how I roll. 🤷‍♂️

My stream of consciousness for this is outlined in guard/rb-inotify#66 at guard/rb-inotify#66 (comment)

[ttilley]

special ping to @thibaudgg as I would like your feedback to that comment specifically before proceeding.

EDIT: I need your input on this before I can do anything at all. Like I mentioned in the referenced comment, I come and go from this project in an unpredictable manner. This makes it less than wise for me to have the final say in long-term vision. The comment outlines my best advice but you need to have the final say. @ioquatix appears to be overqualified to have an opinion here if you'd rather defer to him instead.

[ioquatix]

I'm also a mac developer with C/C++ experience so let me know if I can help.

Also, I think initially, FFI was only a suggestion, not a hard requirement. In the end - it's really what makes it easier and better - the internal design is up to you.

If it makes sense (and less breaking) to just keep using the binary approach, I'm okay with that.

Is it possible to use FFI to access the appropriate APIs without needing a compiled library?

[ttilley]

rb-fsevent has been plagued on and off with tricky bugs involving the passing of signals to the fsevent_watch subprocess. At one point a change in the behavior of guard itself necessitated rewriting signal handling in rb-fsevent to not break things.

There is also a bug where sometimes, for no sane reason, the fsevent_watch process is hanging around after the parent process is long gone. For people who experience this bug and also never turn off their machines (instead putting them to sleep)... eventually the lower level fsevents service will start rejecting requests to watch the filesystem. And I don't mean just from rb-fsevent. I am unable to reproduce this bug and thus have little motivation to dig deeper.

The communication format between parent and child process isn't nearly as well thought out as I thought it was at first. I had a plan at one point to move to otnetstring (an optimized variant of tagged netstrings that makes much more sense to me and is very easy to work with), but then I got distracted by other life events. Anyways, there is also a bug where if your file path looks sufficiently similar to the syntax I use for passing messages, then those events never make it to the library user.

All of the above bugs go away if I'm not using a subprocess. The biggest concern for me is the horrible horrible things we have to do to work around an HFS+ caching bug in 10.7-10.11 and having that occur in the main ruby process rather than isolated in the subprocess.

It is not, however, possible to use FFI to access the appropriate APIs without needing a compiled library. It is also not possible to perform the necessary workarounds without a compiled library. I don't see why this is an issue because I've been compiling (and signing with my personal Developer ID certificate) fsevent_watch for users ahead of time for the entirety of my contribution to this library and provide rake tasks to recompile if you're running an older system than i'm able to target (the underlying code still supports 10.6 if I was too lazy to clean it out and let me tell you... I'm lazy as fuck when I can get away with it).

[ttilley]

Before offering assistance, you should look at the depth of the cthulu insanity level BS happening here: https://github.com/thibaudgg/rb-fsevent/blob/master/ext/fsevent_watch/FSEventsFix.c ;)

Ignore the initial comment block, it's from an earlier attempt and not in any way accurate. The custom realpath uses CoreFoundation.

...actually, you might want to read that code anyways just out of perverse curiosity.

[ioquatix]

Uh, is this for real?

Like, how does apple even use their own API if it's that broken?

[ttilley]

It's a VERY tricky bug, and sometimes just looking at it the wrong way makes it disappear. Describing it as an HFS+ caching bug is actually a bit simplistic as it's a series of bugs at multiple levels that have to happen at the same time for the issue to occur. I wouldn't go so far as to say it results in filesystem corruption... but it does result in completely faulty metadata in the filesystem so it's pretty close.

The bug does not exist in 10.6, and was fixed in 10.12 after years of back and forth with Apple. It took that long to devise a way to reliably reproduce it and test for it... and the tech was absolutely horrified to discover that the problem existed somewhere on the filesystem of almost every machine they tested.

[ttilley]

lol @thibaudgg... I need more than a thumbs up emoji man. 😆

[ttilley]

Another thing to think about, regarding that wiki page... There are details we were very politely asked not to disclose. There's no gag order or NDA, but you most certainly don't bite the hand that feeds you. I believe that describing it as a metadata issue is probably sufficient... with a footnote that the kernel, realpath(), and various other APIs (both POSIX and Apple) would all disagree about the name of a path and that this is the root of the problem. The kernel would report an event using a path that the userspace was not looking for, so the event wouldn't propagate unless the software was explicitly watching all paths (like Apple's Time Machine backup software, which miraculously continued to work despite the bug, but would result in backups that disagree with the original regarding the case/name of any number of files and directories).

[ttilley]

I'm also thinking --my-filesystem-is-broken is probably sufficient vinegar for enabling those hacks. It stresses the importance of upgrading to 10.12 without being a dick about it.

[ioquatix]

So you are saying that Time Machine is basically broken for 10.6 .. 10.11?

[ttilley]

Calling it broken is a bit of an exaggeration considering that the filesystem is case preserving but case insensitive. No, instead the backup would preserve an incorrect form of the path... and restoring from backup wouldn't cause any problems because, again, the filesystem is case insensitive. Nothing would stop working or work differently outside of filesystem monitoring. It was, essentially, an invisible bug that broke nothing... another reason why nobody ever noticed. The issue existed between 10.7 and 10.11. 10.6 and 10.12 function as intended. The bug also doesn't exist in any way whatsoever if you're using the (non-default) case sensitive version of HFS+. This is why I use case sensitive HFS+ even now... (though I have to have Steam, Photoshop, and other braindead software installed to a case insensitive disk image since they break completely if your filesystem is case sensitive... it'll be hilarious to see how they react to APFS, which is ONLY case sensitive right now, with plans to potentially add case insensitivity later)

[ioquatix]

I use case sensitive HFS+ on all my machines :D I refuse to install crap which doesn't work on case sensitive machines :D

[thibaudgg]

lol @thibaudgg... I need more than a thumbs up emoji man. 😆

Yeah, sure, sorry about that, yesterday was a bit packed for me.

I completely agree with your comment about leaving rb-fsevent untouched. My initial idea was also just to increase the gem version and add a simple post_install_message explaining the move to listen-fsevents. As you said a lot of people depends on the current state of the gem, and I see no reason either to change it. That move also gives us (essentially you!) more liberty to take drastic choices around listen-fsevents. I would personally rather have a simpler gem that only works on 10.12, uses FFI, supports only latest Ruby version (if useful for some technical reasons), and drops hackish pieces of baggage (even if you worked hard on them 💪).

If rb-fsevent and listen-fsevents gems co-exist, listen could easily use one or the other based on the macOS version and notify the user about his/her broken file systems. The new "untouched" rb-fsevent version would also inform the user about the same thing and encourage the upgrade to 10.12 and listen-fsevents.

On the technical decisions (using FFI or not, ...) around listen-fsevents it's really up to you, @ttilley, to decide. This gem is definitely yours since version ~0.4. Thank you a lot for all your hard work, it's really really appreciated 💟.

[ttilley]

@thibaudgg ok. I'll start out without hacks, at least... especially since the latest xcode appears to only include the 10.12 SDK anyways!

Aya:~ ttilley$ ls -l /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
total 4
drwxr-xr-x 4 root wheel 170 May  3 18:36 MacOSX.sdk
lrwxr-xr-x 1 root wheel  10 Apr 14 20:46 MacOSX10.12.sdk -> MacOSX.sdk

...so unless I'm missing something, I'm currently unable to target older versions of MacOS if I go the pre-compiled route for the dylib files (even though the "deployment" option still exists and goes back to 10.6, this is misleading without an older SDK available).

10.12 only it is I guess.

[ioquatix]

@ttilley Replying specifically to your comment about SDK versions.

I ran into the same problem when compiling things using Teapot.

I settled on using the "MacOSX.sdk" rather than a versioned one.

That SDK supports older versions of Mac OS X, you just need to run clang++ -mmacosx-version-min=10.6 ... and it will ensure that you don't use parts of the SDK that are not available to you.