git/compat/fsmonitor, branch v2.40.2

Merge branch 'jh/fsmonitor-darwin-modernize'

2022-12-19T02:46:14Z

Stop using deprecated macOS API in fsmonitor. * jh/fsmonitor-darwin-modernize: fsmonitor: eliminate call to deprecated FSEventStream function

fsmonitor: eliminate call to deprecated FSEventStream function

2022-12-15T00:08:27Z

Replace the call to `FSEventStreamScheduleWithRunLoop()` function with the suggested `FSEventStreamSetDispatchQueue()` function. The MacOS version of the builtin FSMonitor feature uses the `FSEventStreamScheduleWithRunLoop()` function to drive the event loop and process FSEvents from the system. This routine has now been deprecated by Apple. The MacOS 13 (Ventura) compiler tool chain now generates a warning when compiling calls to this function. In DEVELOPER=1 mode, this now causes a compile error. The `FSEventStreamSetDispatchQueue()` function is conceptually similar and is the suggested replacement. However, there are some subtle thread-related differences. Previously, the event stream would be processed by the `fsm_listen__loop()` thread while it was in the `CFRunLoopRun()` method. (Conceptually, this was a blocking call on the lifetime of the event stream where our thread drove the event loop and individual events were handled by the `fsevent_callback()`.) With the change, a "dispatch queue" is created and FSEvents will be processed by a hidden queue-related thread (that calls the `fsevent_callback()` on our behalf). Our `fsm_listen__loop()` thread maintains the original blocking model by waiting on a mutex/condition variable pair while the hidden thread does all of the work. While the deprecated API used by the original were introduced in macOS 10.5 (Oct 2007), the API used by the updated code were introduced back in macOS 10.6 (Aug 2009) and has been available since then. So this change _could_ break those who have happily been using 10.5 (if there were such people), but these two dates both predate the oldest versions of macOS Apple seems to support anyway, so we should be safe. Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano

fsmonitor--daemon: on macOS support symlink

2022-11-08T21:36:09Z

Resolves a problem where symbolic links were not showing up in diff when created or modified. kFSEventStreamEventFlagItemIsSymlink is also treated as a file update. This is because kFSEventStreamEventFlagItemIsFile is not included in FSEvents when creating or deleting symbolic links. For example: $ ln -snf t test fsevent: '/path/to/dir/test', flags=0x40100 ItemCreated|ItemIsSymlink| $ ln -snf ci test fsevent: '/path/to/dir/test', flags=0x40200 ItemIsSymlink|ItemRemoved| fsevent: '/path/to/dir/test', flags=0x40100 ItemCreated|ItemIsSymlink| Signed-off-by: srz_zumix Signed-off-by: Taylor Blau

fsmonitor OSX: compile with DC_SHA1=YesPlease

2022-10-19T16:34:47Z

As we'll address in subsequent commits the "DC_SHA1=YesPlease" is not on by default on OSX, instead we use Apple Common Crypto's SHA-1 implementation. In 6beb2688d33 (fsmonitor: relocate socket file if .git directory is remote, 2022-10-04) the build was broken with "DC_SHA1=YesPlease" (and probably other non-"APPLE_COMMON_CRYPTO" SHA-1 backends). So let's extract the fix for this from [1] to get the build working again with "DC_SHA1=YesPlease". In addition to the fix in [1] we also need to replace "SHA_DIGEST_LENGTH" with "GIT_MAX_RAWSZ". 1. https://lore.kernel.org/git/c085fc15b314abcb5e5ca6b4ee5ac54a28327cab.1665326258.git.gitgitgadget@gmail.com/ Signed-off-by: Eric DeCosta Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

fsmonitor: deal with synthetic firmlinks on macOS

2022-10-05T18:05:23Z

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 Signed-off-by: Junio C Hamano

fsmonitor: avoid socket location check if using hook

2022-10-05T18:05:23Z

If monitoring is done via fsmonitor hook rather than IPC there is no need to check if the location of the Unix Domain socket (UDS) file is on a remote filesystem. Signed-off-by: Eric DeCosta Signed-off-by: Junio C Hamano

fsmonitor: relocate socket file if .git directory is remote

2022-10-05T18:05:22Z

If the .git directory is on a remote filesystem, create the socket file in 'fsmonitor.socketDir' if it is defined, else create it in $HOME. Signed-off-by: Eric DeCosta Signed-off-by: Junio C Hamano

fsmonitor: refactor filesystem checks to common interface

2022-10-05T18:05:22Z

Provide a common interface for getting basic filesystem information including filesystem type and whether the filesystem is remote. Refactor existing code for getting basic filesystem info and detecting remote file systems to the new interface. Refactor filesystem checks to leverage new interface. For macOS, error-out if the Unix Domain socket (UDS) file is on a remote filesystem. Signed-off-by: Eric DeCosta Signed-off-by: Junio C Hamano

fsmonitor: option to allow fsmonitor to run against network-mounted repos

2022-08-12T04:03:09Z

Though perhaps not common, there are use cases where users have large, network-mounted repos. Having the ability to run fsmonitor against network paths would benefit those users. Most modern Samba-based filers have the necessary support to enable fsmonitor on network-mounted repos. As a first step towards enabling fsmonitor to work against network-mounted repos, introduce a configuration option, 'fsmonitor.allowRemote'. Setting this option to true will override the default behavior (erroring-out) when a network-mounted repo is detected by fsmonitor. Signed-off-by: Eric DeCosta Signed-off-by: Junio C Hamano

Merge branch 'jh/builtin-fsmonitor-part3'

2022-06-10T22:04:15Z

More fsmonitor--daemon. * jh/builtin-fsmonitor-part3: (30 commits) t7527: improve implicit shutdown testing in fsmonitor--daemon fsmonitor--daemon: allow --super-prefix argument t7527: test Unicode NFC/NFD handling on MacOS t/lib-unicode-nfc-nfd: helper prereqs for testing unicode nfc/nfd t/helper/hexdump: add helper to print hexdump of stdin fsmonitor: on macOS also emit NFC spelling for NFD pathname t7527: test FSMonitor on case insensitive+preserving file system fsmonitor: never set CE_FSMONITOR_VALID on submodules t/perf/p7527: add perf test for builtin FSMonitor t7527: FSMonitor tests for directory moves fsmonitor: optimize processing of directory events fsm-listen-darwin: shutdown daemon if worktree root is moved/renamed fsm-health-win32: force shutdown daemon if worktree root moves fsm-health-win32: add polling framework to monitor daemon health fsmonitor--daemon: stub in health thread fsmonitor--daemon: rename listener thread related variables fsmonitor--daemon: prepare for adding health thread fsmonitor--daemon: cd out of worktree root fsm-listen-darwin: ignore FSEvents caused by xattr changes on macOS unpack-trees: initialize fsmonitor_has_run_once in o->result ...