fanotify backend #180
fanotify backend #180
Conversation
src/linux/FAnotifyFsBackend.cc
Outdated
| #include "FAnotifyFsBackend.hh" | ||
|
|
||
| void FAnotifyFsBackend::start() { | ||
| throw std::runtime_error("not implemented"); |
There was a problem hiding this comment.
I don't know if we'd want to have an unimplemented backend here. And I'm unsure if we'd even end up implementing this one due to the elevated system permissions that it requires (CAP_SYS_ADMIN)
There was a problem hiding this comment.
fixed
'fanotify-fs' backend is completely removed from the code
| @@ -0,0 +1,2491 @@ | |||
| { | |||
There was a problem hiding this comment.
this file should not be added since the project uses yarn
| res.Set(String::New(env, "type"), String::New(env, type.c_str())); | ||
| res.Set(String::New(env, "pathFrom"), String::New(env, pathFrom.c_str())); | ||
| res.Set(String::New(env, "pathTo"), String::New(env, pathTo.c_str())); | ||
| res.Set(String::New(env, "type"), String::New(env, (isMoved ? "move" : isCreated ? "create" : isDeleted ? "delete" : "update"))); |
There was a problem hiding this comment.
This would need to be done in a major version, with parity across all watcher backends. We need to ensure that the events emitted are consistent across platforms so that consumers can rely on the behavior.
There was a problem hiding this comment.
This is a new backend and using it would be on an opt-in basis, so it's not a breaking change. Unfortunately, you can't reliably implement move with other backends - that's the motivation for introducing this new backend - to be able to reliably be able to detect and track move events
There was a problem hiding this comment.
I think we could also introduce an option for move. The backend could emit separate create and delete events for a move by default to remain compatible with the other backends. Or you could opt-in to having it emit a move event instead
#87