> -----Original Message----- > From: Jeff Hostetler <git@xxxxxxxxxxxxxxxxx> > Sent: Tuesday, September 6, 2022 1:14 PM > To: Eric DeCosta <edecosta@xxxxxxxxxxxxx>; Eric DeCosta via GitGitGadget > <gitgitgadget@xxxxxxxxx>; git@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v4 4/4] fsmonitor: normalize FSEvents event paths to > the real path > > > > On 9/2/22 12:35 PM, Eric DeCosta wrote: > > > > > >> -----Original Message----- > >> From: Jeff Hostetler <git@xxxxxxxxxxxxxxxxx> > >> Sent: Thursday, September 1, 2022 4:06 PM > >> To: Eric DeCosta via GitGitGadget <gitgitgadget@xxxxxxxxx>; > >> git@xxxxxxxxxxxxxxx > >> Cc: Eric DeCosta <edecosta@xxxxxxxxxxxxx> > >> Subject: Re: [PATCH v4 4/4] fsmonitor: normalize FSEvents event paths > >> to the real path > >> > >> > >> > >> On 8/31/22 12:09 PM, Eric DeCosta via GitGitGadget wrote: > >>> From: Eric DeCosta <edecosta@xxxxxxxxxxxxx> > >>> > >>> Consider the following network working directory that is mounted > >>> under > >>> /System/Volumes/Data: > >>> > >>> /network/working/directory > >>> > >>> The git working directory path is: > >>> > >>> /System/Volumes/Data/network/working/directory > >>> > >>> The paths reported by FSEvents always start with /network. fsmonitor > >>> expects paths to be under the working directory; therefore it fails > >>> to match /network/... and ignores the change. > >> > >> I'm not sure I understand what's going on here. > >> Are you saying that FSEvents reports network mounted directories with > >> a path relative to the mount-point rather than an absolute path? > >> > > > > Yes > > > >> In your example, is "/network/working/directory" a valid path on your > >> system (that also happens to be the same directory as > >> "/System/Volumes/...") > >> > >> That is, do you have some aliasing going on where both paths are > >> valid -- like a pair of hard-linked directories? > >> Or, is there something special about a network mount point? > >> > >> > >> Did you have to "cd /System/Volumes/..." to get Git to have the > >> absolute path be this? Or were you doing a "cd /network/..."? > >> (Sorry to ask so many questions but I don't have a pair of systems to > >> test any of this on right now.) > >> > > > > "/network/working/directory" is mounted under > > "/System/Volumes/Data/network/working/directory" > > > > There is also a symlink: > > > > "/network" -> "/System/Volumes/Data/network" > > > > No matter if I "cd /System/Volumes/Data/network/working/directory" > > or "cd /network/working/directory" the paths reported by FSEvents > > always start with "/network/working/directory" > > > > If I do a similar symlink with local directories, I do not get this > > unexpected behavior. > > > > I need to remove the symlink and try it that way, but I need to > > coordinate with the machine's owner. > > > I think you have stumbled upon a recent MacOS feature called "firmlinks". > I'm just reading up on it myself, so I shouldn't speculate here (yet), but > maybe you too could do some reading on the subject. > > This makes me wonder if the symlink is historical. The real magic is in the > firmlinks. For example, if I do: > > $ (cd / ; ls -l | grep Users) > drwxr-xr-x 6 root admin 192 Apr 6 2020 Users > > $ (cd /Users ; df .) > Filesystem 512-blocks Used Available Capacity iused ifree %iused Mounted > on > /dev/disk1s1 976490576 608954344 338850488 65% 4181323 4878271557 0% > /System/Volumes/Data > > we can see that /Users is on /System/Volumes/Data (and there is a > /System/Volumes/Data/Users directory with the same metadata), but it is > not a symlink. > > > See [1] for more info. > > [1] > http://www.swiftforensics.com/2019/10/macos-1015-volumes-firmlink- > magic.html <https://protect- > us.mimecast.com/s/QN4qCYEZB2h1p7jWcG1Cbw?domain=swiftforensics.co > m> > > Hmm, I don't see anything that suggests a firmlink is involved but this is new to me so maybe I just don't see it. There is an automount in addition to the symlink though. So, dispensing with the abstract "/network" path, and getting to the details of my environment: % mount | grep /mathworks map auto.sfs.sol2.mathworks on /System/Volumes/Data/mathworks (autofs, automounted, nobrowse) triggered map auto.sfs.sol2.devel on /System/Volumes/Data/mathworks/devel (autofs, automounted, nobrowse) triggered map sfs.worldwide.US-Natick.sol2.devel.sbs on /System/Volumes/Data/mathworks/devel/sbs (autofs, automounted, nobrowse) triggered map sfs.worldwide.US-Natick.devel.sbs.29 on /System/Volumes/Data/mathworks/devel/sbs/29 (autofs, automounted, nobrowse) batfs-sb29-nfs:/vmgr/sbs29/edecosta.Bbashprod1.j1928560.2 on /System/Volumes/Data/mathworks/devel/sbs/29/edecosta.Bbashprod1.j1928560.2 (nfs, nodev, automounted, noatime, nobrowse) ... % ls -l / | grep mathworks lrwxr-xr-x 1 root wheel 35 Aug 29 10:25 home@ -> /System/Volumes/Data/mathworks/home lrwxr-xr-x 1 root wheel 30 Aug 29 10:25 mathworks@ -> /System/Volumes/Data/mathworks My worktree is: /System/Volumes/Data/mathworks/devel/sbs/29/edecosta.Bbashprod1.j1928560.2 or, equivalently via the symlink just: /mathworks/devel/sbs/29/edecosta.Bbashprod1.j1928560.2 I have sudo'ers access now; so I can try mounting things manually, mess about with symlinks and see what I get. > [...] > >>> @@ -209,7 +209,12 @@ static void > >> fsevent_callback(ConstFSEventStreamRef streamRef, > >>> /* > >>> * On Mac, we receive an array of absolute paths. > >>> */ > >>> - path_k = paths[k]; > >>> + if (fsm_settings__get_allow_remote(the_repository) > 0) { > >>> + strbuf_reset(&tmp); > >>> + strbuf_realpath_forgiving(&tmp, paths[k], 0); > >>> + path_k = tmp.buf; > >>> + } else > >>> + path_k = paths[k]; > >> > >> This feels wrong. > >> > >> It is not that fsmonitor.allowRemote is true, but whether or not this > >> particular file system *IS* remote, right? > > > > True. I suppose each path could be checked, or some bit could be set > > if the working directory is remote, perhaps along the lines of > > fsmonitor_ipc__get_path. Then the determination of the IPC path > > and whether it is remote would be in one place. fsm-settings-* > > would then just get that bit and check it against allowRemote. > > > > Thoughts? > > I'll do some digging here. There ought to be a way to tell if a > component directory in a pathname has a firmlink peer. (But I'm > traveling for GitMerge, so I might not have time to look at this > until afterwards.) > > This would indicate that a "bi-directional wormhole" (their words) > alias is available (and hopefully, a way to computer the other peer....) > > I'm thinking that the "/network/..." path in the FSEvents is because > FSEventD is using a particular peer spelling (that we weren't > expecting). > > If we can compute the spellings of the peers once when the daemon > starts up (and maybe make a little dictionary), then we can do > prefix tricks on the absolute path after the > path_k = paths[k]; > step in fsevent_callback() to extract a relative path rather than > an absolute path. > > Then call fsmonitor_classify_path_relative() instead of _absolute(). > > Watch out though, there are several places that do > rel = path+k + ...state->path_worktree_watch.len... > that would need to be adjusted. > > Hope this helps, > Jeff > > Thanks for the insights, I'll dig around and test things out some more. -Eric
