Re: Option to allow fsmonitor to run against repos on network file systems

[Jeff Hostetler <git@jeffhostetler.com>]

On 6/30/22 1:11 PM, Eric D wrote:
> I can appreciate the concerns expressed here:
> https://github.com/git/git/commit/d989b266c1a7ef47f27cec75e90f3dfefbfa0200
> 
> However, in my environment, our file servers are very capable and have
> the requisite support. It would be great if there was an option to
> override this check and allow fsmonitor to operate against network
> filesystems.

Yeah, I was just being cautious.  I probably should have also added
concerns on the remote system being an actual Windows server or a
non-Windows host running SAMBA.  There were just too many combinations
for me to be comfortable enabling it by default (on the initial
release, at least).

Also, the ReadDirectoryChangesW() API limits the buffer size to 64k
for remote handles (because of protocol limitations), so there _may_
be more of an opportunity for dropped events on very busy remote file
systems.  (I never saw any dropped events in my testing (without
intentionally breaking things), but it is a possible concern, so again,
caution and safety...)  And I do handle dropped events and force a
resync and send the client a "trivial" response (so it must do a regular
scan), so output is still correct, but slower.


Having said all of that, I did do lots of testing and never had an
issue with remote drives actually working correctly, so I think it'd
be fine allow a config setting to optionally allow it.  I just didn't
want to clutter up things in advance if no one actually wanted to
use it on remote file systems.


I think it would be fine to have a "fsmonitor.allowRemote" or
"fsmonitor.allowWindowsRemote" config setting and default them to false
for now.  Or until we learn which combinations of remote mounts are
safe and/or problematic.

Jeff