search

msys2 / MSYS2-packages

Package scripts for MSYS2.
https://packages.msys2.org
BSD 3-Clause "New" or "Revised" License
1.3k stars 489 forks source link

Startup MSys2 slow with mapped network drives #954

Open wickedmic opened 7 years ago

wickedmic commented 7 years ago

When I start mintty it takes several second until it is ready and I have a bash prompt. Sometimes this also happens after returning from a program.

I tried some of the solutions mentioned in issue 138, but nothing seems to apply to my situation (I'm on a standalone Win7 Machine).

But when I unmount all my network drives the slowdown is gone.

I understand that dealing with network shares might be slow, but always disconnecting all my network shares just to be able to use msys2 without slowdowns seems a bit excessive.

ErichDonGubler commented 7 years ago

What shell do you use? What sort of prompt/Bash configuration do you have? I don't know a whole lot about how MSYS2's default Bash configuration interacts with networked resources, but your configuration probably matters in this case.

ermingol23 commented 3 years ago

I have noticed that if I start a subshell from within for instance Git Bash, e.g. I have extracted the source tar.gz of FFMpeg-4.4 on a network share and do this from within the FFMpeg 4.4 folder

$ time ls -R | wc -l
7752

real    2m18.092s
user    0m0.374s
sys     0m5.014s

$ # Start new subshell and redo
$ bash
$ time ls -R | wc -l
7752

real    0m0.377s
user    0m0.062s
sys     0m0.233s

$

That is file accesses are much faster when doing them from within a subshell! After a bit further digging I noticed that there are excessive amounts of data transfered over the network during the execution of ls. It is as if not only the file names are transferred but the whole contents of the files are transferred just for listing the content of a directory!

Furthermore, if I disable sourcing of /etc/profile.d/git-prompt.sh there is no longer any sluggishness. After some further testing I get the impression that there mere activation of tab completion support causes the whole issue!

And using git from command line without tab completion is a real is not very comfortable (especially when it comes to branch names). So that is not a workable workaround.But starting a Bash subshell is actually a workaround that might work...

Perhaps now you have a test case that can be used for tracking down this bug?