Follow-on to the work done to allow Windows to work against network-mounted repos for macOS. Have macOS take advantage of the same configuration option, 'fsmonitor.allowRemote' that was introduced for Windows. Setting this option to true will override the default behavior (erroring-out) when a network-mounted repo is detected by fsmonitor. The added wrinkle being that the Unix domain socket (UDS) file used for IPC cannot be created in a network location; instead $HOME is used if the default location is on the network. The user may, optionally, set the 'fsmonitor.socketDir' configuration option to a valid, local directory if $HOME itself is on the network or is simply not the desired location for the UDS file. An additional issue is that for mount points in the root directory, FSEvents does not report a path that matches the worktree directory due to the introduction of 'synthetic firmlinks'. fsmonitor must map the FSEvents paths to the worktree directory by interrogating the root filesystem for synthetic firmlinks and using that information to translate the path. v8 differs from v7: * incorporates code review feedback * gets the rebase right v7 differs from v6: * incorporates code review feedback v6 differs from v5: * incorporates earlier, Windows-specific changes that have not made it back yet to the master branch * incorporates code review feedback * adds documentation for 'fsmonitor.allowRemote' and 'fsmonitor.socketDir' v5 differs significantly from earlier versions: * redesign of handling 'fsmonitor.allowRemote' and 'fsmonitor.socketDir' such that these options are no longer added to the settings data structure but are rather read from config at point of use * refactoring of code for handling platform-specific file system checks via a common interface to avoid platform #ifdef in IPC code and be in-model with other platform-specific fsmonitor code * dealing with 'synthetic firmlinks' on macOS Eric DeCosta (5): fsmonitor: refactor filesystem checks to common interface fsmonitor: relocate socket file if .git directory is remote fsmonitor: avoid socket location check if using hook fsmonitor: deal with synthetic firmlinks on macOS fsmonitor: add documentation for allowRemote and socketDir options Documentation/git-fsmonitor--daemon.txt | 35 +++++ Makefile | 2 + builtin/fsmonitor--daemon.c | 11 +- compat/fsmonitor/fsm-ipc-darwin.c | 46 ++++++ compat/fsmonitor/fsm-ipc-win32.c | 9 ++ compat/fsmonitor/fsm-listen-darwin.c | 6 +- compat/fsmonitor/fsm-path-utils-darwin.c | 132 +++++++++++++++++ compat/fsmonitor/fsm-path-utils-win32.c | 145 +++++++++++++++++++ compat/fsmonitor/fsm-settings-darwin.c | 70 +++------ compat/fsmonitor/fsm-settings-win32.c | 174 +---------------------- contrib/buildsystems/CMakeLists.txt | 4 + fsmonitor--daemon.h | 3 + fsmonitor-ipc.c | 18 ++- fsmonitor-ipc.h | 4 +- fsmonitor-path-utils.h | 59 ++++++++ fsmonitor-settings.c | 58 +++++++- fsmonitor-settings.h | 2 +- 17 files changed, 541 insertions(+), 237 deletions(-) create mode 100644 compat/fsmonitor/fsm-ipc-darwin.c create mode 100644 compat/fsmonitor/fsm-ipc-win32.c create mode 100644 compat/fsmonitor/fsm-path-utils-darwin.c create mode 100644 compat/fsmonitor/fsm-path-utils-win32.c create mode 100644 fsmonitor-path-utils.h base-commit: d3fa443f97e3a8d75b51341e2d5bac380b7422df Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1326%2Fedecosta-mw%2Ffsmonitor_macos-v8 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1326/edecosta-mw/fsmonitor_macos-v8 Pull-Request: https://github.com/gitgitgadget/git/pull/1326 Range-diff vs v7: 1: 155a6890806 = 1: 155a6890806 fsmonitor: refactor filesystem checks to common interface 2: 075340bd2a7 ! 2: b5356497228 fsmonitor: relocate socket file if .git directory is remote @@ compat/fsmonitor/fsm-ipc-darwin.c (new) + if (ipc_path) + return ipc_path; + -+ if (!r) -+ r = the_repository; -+ + ipc_path = fsmonitor_ipc__get_default_path(); + + /* By default the socket file is created in the .git directory */ 3: 5518d2f3e03 = 3: 6719ca2b24d fsmonitor: avoid socket location check if using hook 4: 3a9fe473cf4 ! 4: d736cb8fa90 fsmonitor: deal with synthetic firmlinks on macOS @@ Commit message Signed-off-by: Eric DeCosta <edecosta@xxxxxxxxxxxxx> + fsmonitor: deal with synthetic firmlinks on macOS + + Starting with macOS 10.15 (Catalina), Apple introduced a new feature + called 'firmlinks' in order to separate the boot volume into two + volumes, one read-only and one writable but still present them to the + user as a single volume. Along with this change, Apple removed the + ability to create symlinks in the root directory and replaced them with + 'synthetic firmlinks'. See 'man synthetic.conf' + + When FSEevents reports the path of changed files, if the path involves + a synthetic firmlink, the path is reported from the point of the + synthetic firmlink and not the real path. For example: + + Real path: + /System/Volumes/Data/network/working/directory/foo.txt + + Synthetic firmlink: + /network -> /System/Volumes/Data/network + + FSEvents path: + /network/working/directory/foo.txt + + This causes the FSEvents path to not match against the worktree + directory. + + There are several ways in which synthetic firmlinks can be created: + they can be defined in /etc/synthetic.conf, the automounter can create + them, and there may be other means. Simply reading /etc/synthetic.conf + is insufficient. No matter what process creates synthetic firmlinks, + they all get created in the root directory. + + Therefore, in order to deal with synthetic firmlinks, the root directory + is scanned and the first possible synthetic firmink that, when resolved, + is a prefix of the worktree is used to map FSEvents paths to worktree + paths. + + Signed-off-by: Eric DeCosta <edecosta@xxxxxxxxxxxxx> + + fsmonitor: deal with synthetic firmlinks on macOS + + Starting with macOS 10.15 (Catalina), Apple introduced a new feature + called 'firmlinks' in order to separate the boot volume into two + volumes, one read-only and one writable but still present them to the + user as a single volume. Along with this change, Apple removed the + ability to create symlinks in the root directory and replaced them with + 'synthetic firmlinks'. See 'man synthetic.conf' + + When FSEevents reports the path of changed files, if the path involves + a synthetic firmlink, the path is reported from the point of the + synthetic firmlink and not the real path. For example: + + Real path: + /System/Volumes/Data/network/working/directory/foo.txt + + Synthetic firmlink: + /network -> /System/Volumes/Data/network + + FSEvents path: + /network/working/directory/foo.txt + + This causes the FSEvents path to not match against the worktree + directory. + + There are several ways in which synthetic firmlinks can be created: + they can be defined in /etc/synthetic.conf, the automounter can create + them, and there may be other means. Simply reading /etc/synthetic.conf + is insufficient. No matter what process creates synthetic firmlinks, + they all get created in the root directory. + + Therefore, in order to deal with synthetic firmlinks, the root directory + is scanned and the first possible synthetic firmink that, when resolved, + is a prefix of the worktree is used to map FSEvents paths to worktree + paths. + + Signed-off-by: Eric DeCosta <edecosta@xxxxxxxxxxxxx> + ## builtin/fsmonitor--daemon.c ## @@ #include "parse-options.h" 5: 4d00adb1deb < -: ----------- fsmonitor: deal with synthetic firmlinks on macOS 6: 260591f5820 = 5: ddf4e3e6442 fsmonitor: add documentation for allowRemote and socketDir options -- gitgitgadget
