search

milke / GitFinder-Issues

Bug and issue tracker for GitFinder - git client with macOS Finder integration
16 stars 1 forks source link

Cannot add an NFS-mounted repository #74

Open lfarv opened 3 years ago

lfarv commented 3 years ago

After upgrading to GitFinder 1.6 and macOS Big Sur, NFS-mounted repositories disappeared from the list of monitored directories, and adding one by dragging or selecting is silently ignored.

milke commented 3 years ago

No errors reported when you try to add NFS-mounted repository to the list? Does it work if you try any local-disk repository? If that doesn't work either, does that at least report any error?

lfarv commented 3 years ago

Thanks for the fast answer ! 1) all the local-disk repositories are correctly registered and monitored, 2) The failing repository is hosted on a Synology NAS, automounted by NFS on my Mac:

bijou:~ $ mount
...
map auto_ds215 on /System/Volumes/Data/ds215 (autofs, nodev, nosuid, automounted, nobrowse)
brava.local:/volume1/machfs on /System/Volumes/Data/ds215/machfs (nfs, nodev, nosuid, automounted, nobrowse)
...
bijou:~ $ ls -l /System/Volumes/Data/ds215/machfs/machine
total 88
...
drwxr-xr-x  10 famille  staff        4096  2 nov 18:06 at
...

If I try to add /System/Volumes/Data/ds215/machfs/machine/at to GitFinder, no message or sound or anything happens, but the list of monitored directories still shows only the local repositories. Does GitFInder manage a log file where I could find more information? Could it come from the automounter? I'll try by manually mounting the remote disk from the Finder.

lfarv commented 3 years ago

It looks indeed like a problem with the macOS automounter. If I remove the automount and mount the disk manually (Connect to server...), the situation is:

bijou:~ $ mount
...
brava.local:/volume1/machfs on /Volumes/machfs (nfs, nodev, nosuid, mounted by famille)

The volume is mounted by the user (famille) and no more by the system. And then GitFinder accepts /Volumes/machfs/machine/at. There is still a problem (which I already encountered several times): I get from time to time a pop-up window saying:

Failed to initialize the application's saved data There was an error creating or loading the application's saved data.

Answering OK clears the popup. So you may consider the issue solved, but if you can help clearing the popup issue…

milke commented 3 years ago

@lfarv, I apologise about the delay, I was busy with some other things… There are actually two issues at hand here.

First issue is automatic mounting of volumes (if they're unmounted), on which the monitored directories (repo folders) reside. GitFinder takes care those volumes are mounted automatically, if possible. That happens when GitFinder is launched, but also every time Repositories in GitFinder preferences window is selected. Of course, volume mounting will happen only if possible. If not (e.g. a monitored directory resides on an unmounted volume on an ejected USB stick), GitFinder will automatically remove that directory from the repo folders list, since it's not valid anymore.

However there is a bug in the current official release, which can cause automatic mounting to fail under certain conditions. Exactly what you've experienced. It's fixed in the latest beta version 1.6.2b1 (build 90). You can directly download it here, or you can automatically update your current copy from GitFinder Updates preferences, just select the Beta release channel.

milke commented 3 years ago

Second issue is a bug, preventing GitFinder to load a commit database (GitFinder creates and maintains a small database of commits for each repository, to enable fast commit search, file history and so on…) on network volumes (or any volume, which doesn't support advisory file locking). This issue is also fixed in the latest beta version 1.6.2b1 (build 90), read above how to update your copy to it.

However, I must admit I haven't tested GitFinder on network volumes at all. I didn't envision people working with repositories on network volumes, due to potentially very degraded performance. I have tried it now, on rather slow network volumes connected wirelessly and it wasn't a great experience at all. Not only with GitFinder, but also with other git UI clients I tried. Also, GitFinder probably isn't designed for slow disk volumes, with its constant automatic updating of UI and git statuses every time some file in the repository change.

So, I just wanted to let you know about it, but maybe it works good enough for you. I'll see what I can do to make future version better in that regard. I'd appreciate if you tell me whether both issues are fixed for you and what's your experiences using GitFinder with repositories on network volumes.

lfarv commented 3 years ago

Hello @milke, I just downloaded and tested your version 1.6.2b1, and here are the results:

So I thought my setup was completely broken, and I tried to start from scratch: I removed the GitFinder application and removed all that I could identify in ~/Library/Cache, Containers, Group Containers, Preferences and Application Scripts.

I reloaded the new application (1.6.2b1, and my license was still there, it must be stored in a place I missed), and restarted slowly: adding and removing local repositories, everything was normal. Then I tried to drag and drop my auto-mounted repository, and got the same behaviour: the repository does not appear, and the - button stops working !!!

So to conclude: adding local directories or manually NFS-mounted directories works. Trying to add an auto-mounted directory (using automount/automountd) fails and blocks the Repositories handling.

lfarv commented 3 years ago

Now concerning network volumes: from my experience, it's quite usual in large organisations to keep data in centralised servers. Here at home with a NAS and a gigabit ethernet network, I cannot see any difference with local files, at least with NFS. I still get a small penalty if I use SMB networking, but I didn't try GitFinder in these conditions.

So GitFinder works nicely on my network (at least when it works…).

So thanks for the application, and for your support !

milke commented 3 years ago

@lfarv, can you please post the contents of your /etc/auto_master file, and any local or network maps it includes? I don't have any NFS network volume at the moment, but I do have some SMB and AFP volumes and I want to try to reproduce this auto-mount behaviour using them. Thanks in advance.

lfarv commented 3 years ago

Hi @milke. Here is my setup:

bijou:~ $ cat /etc/auto_master
#
# Automounter master map
#
+auto_master        # Use directory service
#/net           -hosts      -nobrowse,hidefromfinder,nosuid
/home           auto_home   -nobrowse,hidefromfinder
/Network/Servers    -fstab
/-          -static
/ds215          auto_ds215  -nobrowse,hidefromfinder,nodev,nosuid

In the map auto_ds215, only a single line is active:

bijou:~ $ cat /etc/auto_ds215
# in auto_master:
#/ds215 auto_ds215  -nobrowse,hidefromfinder,nodev,nosuid

#machfs     \
#   /machine    -fstype=nfs,rw,intr brava.local:/volume1/machfs/machine \
#   /appdata    -fstype=nfs,rw,intr brava.local:/volume1/machfs/appdata
machfs          -fstype=nfs,rw,intr brava.local:/volume1/&
#pharefs        -fstype=vboxsf,uid=1000,gid=1000    pharefs
#*          -fstype=nfs,rw,intr brava.local:/volume1/&
milke commented 3 years ago

@lfarv, before I try to replicate your setup, just wondering… Does anything change (meaning, does it work) if you remove nobrowse or hidefromfinder (or both) from that /ds215 line in your /etc/auto_master file?

lfarv commented 3 years ago

Hello @milke. I tried removing both options: now it works ! Then to confirm, I put both options back. And, surprise, it still works…

The only difference is the upgrade to MacOS 11.2 installed recently. Could it be that a problem with the automounter has been fixed in the update ? I confirmed that the problem also disappeared on another machine, but unfortunately I don't have a 11.0 or Catalina machine anymore to check… I can't say anything about 11.1, maybe I did't try with it. And I could not find any details of what has been changed in the OS updates.

Anyway, thanks for your involvement in solving my problem, I hope it was indeed a problem in MacOS.

milke commented 3 years ago

@lfarv, I'd really appreciate if you try a few things and report your findings here. That may help me to realise what the issue was and if it still exists (if it's the OS or GitFinder).

First test:

Second test:

Thanks for your time, effort and support. I hope I'm not asking for much

lfarv commented 3 years ago

Hello @milke, I'm sorry to report that I was about to start your tests when I discovered that I'm back to the "blocked" situation. I tried many things, reinitialising the NVRAM, rebooting the NFS server… Nothing. The problem with GitFinder is strictly correlated with a problem with another software (Matlab) when using shared libraries hosted on the same NFS server. So I'm even more convinced that the problem is NOT in GitFinder but in MacOS, though other software (Finder for instance, or document-based software) are not affected. It does not seem to be linked with my account since it happens on another computer configured differently (but also running Big Sur), while an old machine running High Sierra is not affected. Unfortunately I don't have the possibility to try with another NFS server.

So I'll go back to manual mounting, which seems to avoid all problems.

I want to thank you for the time spent on this very strange problem, you might close the issue (at least remove the "bug" label!).

milke commented 3 years ago

@lfarv, thank you for your continuous tries and testing as well 👍

I will try to replicate your configuration and test it myself. Until I come to come final conclusion I'll leave this issue open. But I accept your suggestion, so changing the label from bug to question.