On 8/19/22 2:38 PM, Eric DeCosta wrote:
-----Original Message-----
From: Jeff Hostetler <git@xxxxxxxxxxxxxxxxx>
Sent: Friday, August 19, 2022 12:50 PM
To: Eric DeCosta via GitGitGadget <gitgitgadget@xxxxxxxxx>;
git@xxxxxxxxxxxxxxx
Cc: Eric DeCosta <edecosta@xxxxxxxxxxxxx>
Subject: Re: [PATCH] fsmonitor: option to allow fsmonitor to run against
network-mounted repos
On 8/18/22 4:48 PM, Eric DeCosta via GitGitGadget wrote:
From: Eric DeCosta <edecosta@xxxxxxxxxxxxx>
[...]
Yes, the point is to allow users to try it out. Self-servingly, I have about
3K users who make heavy use of network-mounted sandboxes on the
three major platforms; all connecting via NFS or SMB to Linux file
servers. Hardly exhaustive, but the file system change notification APIs
(inotify, FSEvents, and ReadDirectoryCHangesW) all seem to work correctly.
Thus my motivation to work on this aspect of git :-)
Perfect. I have to be careful here, I don't want to discourage
experimentation and testing -- and if you have access to a pool of
users who can beat on it, then great let's try it.
At the time, I didn't have such a "captive audience"... :-)
And I just wanted to be sure that everyone understood that some of
these combinations have never been tried....
[...]
As far as multiple client machines mounting the remote repo, I have
doubts that FSMonitor would even see changes made from another
machine. Worth trying out and documenting as needed - might even
be better off being considered as unsupported.
Yeah, that's another dimension. (1) is whether we miss events
that we generated locally. (2) is whether events get relayed to
us from other clients.
There was a suggestion later in this thread about using a SHA-1
or SHA-256 hash of the pathname to avoid the tmp XXXXXX pattern
and just put the socket in $HOME (and omit the need for the new
fsmonitor-daemon.ipc FILE completely). This might work, but we
need to be careful because a user might have hardlinks or symlinks
locally so there may be more than one unique path to the repo
on the local system. (It is OK to have more than one daemon
listening to a repo, just less efficient.)
Ah, I see.
As an interim step, you might try using my original socket code
plus just the config.allowRemote=true change. And test it on a
mounted repo where you've converted the .git directory to a .git
file and moved contents of the .git directory to somewhere local.
Then the UDS would be created in the local GITDIR instead of on
the remote system. This won't help any of the sharing cases I
described above, but will let you experiment with getting remote
events.
Within the context of the environment that I have available to me
(macOS over NFS to a Linux file server), FSEvents is working correctly.
I can make changes at any arbitrary place inside of the repo and an
event is generated.
It's looking like that the Unix domain socket (UDS) file should remain
where it is unless fsmonitor.allowRemote is true.
If fsmonitor.allowRemote is true then the UDS file can be located
in $HOME with the caveat that if there is more than one path to
the repo (via hard or sym links) that things might not work as
expected. I think that's OK given the experimental nature of the
feature.
Yeah, I'd experiment with moving the UDS to $HOME (assuming you don't
remote mount home directories too) and see how it works for you.
Later, after we have more experience with it, we can talk about just
having it always be in $HOME.
Jeff
