//FREE\\ Download Fsmonitor
Quinten Moye
The fsmonitor daemon does not currently know about submodules and doesnot know to filter out filesystem events that happen within asubmodule. If fsmonitor daemon is watching a super repo and a file ismodified within the working directory of a submodule, it will reportthe change (as happening against the super repo). However, the clientwill properly ignore these extra events, so performance may be affectedbut it will not cause an incorrect result.
By default, the fsmonitor daemon refuses to work with network-mountedrepositories; this may be overridden by setting fsmonitor.allowRemote totrue. Note, however, that the fsmonitor daemon is not guaranteed to workcorrectly with all network-mounted repositories, so such use is consideredexperimental.
By default, the socket is created in the .git directory. However, if the.git directory is on a network-mounted filesystem, it will instead becreated at $HOME/.git-fsmonitor-* unless $HOME itself is on anetwork-mounted filesystem, in which case you must set the configurationvariable fsmonitor.socketDir to the path of a directory on a Mac OS nativefilesystem in which to create the socket file.
If none of the above directories (.git, $HOME, or fsmonitor.socketDir)is on a native Mac OS file filesystem the fsmonitor daemon will report anerror that will cause the daemon and the currently running command to exit.
This Mac OS-specific option, if set, specifies the directory inwhich to create the Unix domain socket used for communicationbetween the fsmonitor daemon and various Git commands. The directory mustreside on a native Mac OS filesystem. Only respected when core.fsmonitoris set to true.
However, Git added support for an external file system monitor in version 2.16.0 using the core.fsmonitor hook. Here, clients communicate with a proxy child helper process through the hook interface, and it communicates with an external file system monitor process.
I've just compiled unison 2.48.4 for my own. It works perfectly after normal call but unison-fsmonitor doesn't deect any filesystem changes and doesn't synchronize anything. Filesystem is EXT4.-debug all/verbose doesn't bring any log. The only thing it puts on the terminal is VERSION 1, after hitting any key it terminates with message: ERROR unknown%20command%20''No mater whether invoked with sudo or as regular user.Nothing in /.unison/unison.logAny ideas about the possible reasons? Any ideas how to debug it?
The executable unison-fsmonitor is not meant to be run on its own, but is instead just a tool that Unison uses to watch your filesystem. To have Unison watch your filesystem for changes just run unison with the line repeat=watch in your profile, or from the command line run
What security profile did you enable? Maybe it has some kind of restrictions. I installed perl and git-core on my system, and then copied that fsmonitor-watchman.sample to a standard user and ran it without problems. I did not choose a security profile during install, but I do have selinux enabled.
I noticed that both the code and the binary doesn't include fsmonitor.py nor unison-fsmonitor so users are unable to use -repeat watch function of unison.
It is however included in the original (devs website) in version 2.40
Is that done purposely?
This issue is forcing me to create my own package - the `-repeat watch` functionality is essential! And unison-fsmonitor is already compiled successfully by the package build script - we just don't package it.
I get the same output if I try to run the same command (reversing the ssh) form inside the VM. I've read that the unison-fsmonitor should comply with the protocol described in /src/fswatch.ml and this doesn't seem to be the case for the default fsmonitor.py script. Am I missing something? Is there another script that should be used for the unison-fsmonitor executable instead?
When you compile Unison from source, there is a separate executable unison-fsmonitor that is created. When you run this unison-fsmonitor it prints VERSION 1 and then waits as expected. Just compile Unison on your VM and use that executable instead of the fsmonitor.py script.
You can see in the change-log for Unison 2.48.3 that they created a new file-watcher utility. It's not clear to me why fsmonitor.py is included in this release if you are supposed to use the new utility. Or maybe the new utility and the python script actually perform different tasks ... ?
On windows, Sourcetree.exe will start "git.exe fsmonitor--daemon run" process for every local repository(even not opened in tab), I didn't found how to disable this feature, and what's worse, those process will keep running/existing after I close/shutdown the SourceTree.exe, and it'll prevent any action on my local repository folder, I have to kill them all one by one in task manager. It's strange, and kind of bug.
Most Git commands will invoke the command specified in core.fsmonitor, if set, as soon as they need to query information about files present in the local repository, among which are git status and git diff.
The root cause of this vulnerability is similar for most prompts and the majority are vulnerable by default. As soon as a Git command with support for the directive core.fsmonitor is invoked, the arbitrary command is executed.
The unison-fsmonitor utility is an add-on for Unison that monitors your disk and initiates a sync between Tokaido and your local system. Sadly, this requires a little bit of manual installation for Linux users.
f5d0e4f075