Windows explorer hanging when right click in WSL

[Johan Laneau]

Hi,

We are experiencing an issue with TortoiseSVN. When we right click in Windows explorer on a file or folder that is part of a SVN working copy that checked our under WSL, the explorer window hangs (between 15 seconds and 45 seconds) and only after that show the right click menu.

The issue is not present when TortoiseSVN is not installed. We tested both versions 1.14.5 and 1.14.7 and have the same results.

This issue was already described earlier in https://stackoverflow.com/questions/72317768/right-click-in-windows-on-a-svn-folder-shared-in-wsl-takes-forever-why. However, the solution mentioned there does not work for us. 

We can partially resolve the issue by adding "\\wsl$\*" to "settings", "general", "Context Menu", "Do not show the context menu for the following paths". When doing this, the duration of the hung state appears reduced to 15econds to 20seconds instead of more than 40seconds.

Note that we do not require TortoiseSVN to work on files located in the WSL drive. This appears to be blocked by an incompatibility of the WSL filesystem and SVN (see https://github.com/microsoft/WSL/issues/4689). We just want to avoid the hung state such that we can use the context menu for other actions on those files. Can you tell us how to configure the settings accordingly? Or fix this in TortoiseSVN itself?

Thanks already,

Johan Laneau

[Daniel Sahlberg]

tisdag 10 september 2024 kl. 16:30:30 UTC+2 skrev johan....@gmail.com:

Hi,

We are experiencing an issue with TortoiseSVN. When we right click in Windows explorer on a file or folder that is part of a SVN working copy that checked our under WSL, the explorer window hangs (between 15 seconds and 45 seconds) and only after that show the right click menu.

The issue is not present when TortoiseSVN is not installed. We tested both versions 1.14.5 and 1.14.7 and have the same results.

This issue was already described earlier in https://stackoverflow.com/questions/72317768/right-click-in-windows-on-a-svn-folder-shared-in-wsl-takes-forever-why. However, the solution mentioned there does not work for us. 

We can partially resolve the issue by adding "\\wsl$\*" to "settings", "general", "Context Menu", "Do not show the context menu for the following paths". When doing this, the duration of the hung state appears reduced to 15econds to 20seconds instead of more than 40seconds.

I noticed that sometimes, Windows would redirect \\wsl$\XYZ to \\wsl.localhost\XYZ, so adding \\wsl$\* didn't help. I had to add \\wsl.localhost\* (as hinted in the above article) to get it working reliably.

Do you have any other applications adding to the context menu that might account for the remaining seconds? (For example, TortoiseGit is adding a context menu much in the same way as TortoiseSVN, but I din't know how affected Git might be by limitations of the WSL subsystem.

Note that we do not require TortoiseSVN to work on files located in the WSL drive. This appears to be blocked by an incompatibility of the WSL filesystem and SVN (see https://github.com/microsoft/WSL/issues/4689). We just want to avoid the hung state such that we can use the context menu for other actions on those files. Can you tell us how to configure the settings accordingly? Or fix this in TortoiseSVN itself?

I'm guessing that this is mostly because TortoiseSVN tries to search for a working copy database (.svn folder) and accessing the WSL storage from Windows is not very performant (probably exaggerated by accessing the issues the SQLite database is having with Windows/WSL's limited support for file locking). The best solution is probably getting the setting above working. There is probably only little that can be done within TortoiseSVN.

Kind regards,

Daniel

[Johan Laneau]

Hi Daniel,

We already tried using the two alias for WSL disk:

\\wsl.localhost\*

\\wsl$\*

It does not help. On our systems the "\\wsl.localhost\*" setting does not give any difference.

We also know that the "hanging" is only caused by TortoiseSVN because un-installing TortoiseSVN removes the hanging and re-installing puts the problem back. We also do not have TortoiseGIT installed. We also see it is caused by TortoiseSVN because it only happens when you right-click on a file/folder that is inside a SVN working copy. Right-clicking on other files inside WSL does not cause the hanging.

Are there any traces we can make to investigate where the hanging is coming from?

Johan Laneau

--
You received this message because you are subscribed to a topic in the Google Groups "TortoiseSVN" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tortoisesvn/BjYlMU4Bg6A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tortoisesvn...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/96ef5a73-1e2b-4839-966a-1e4550eb3e80n%40googlegroups.com.

[Daniel Sahlberg]

söndag 15 september 2024 kl. 18:17:54 UTC+2 skrev johan....@gmail.com:

Hi Daniel,

We already tried using the two alias for WSL disk:

\\wsl.localhost\*

\\wsl$\*

It does not help. On our systems the "\\wsl.localhost\*" setting does not give any difference.

We also know that the "hanging" is only caused by TortoiseSVN because un-installing TortoiseSVN removes the hanging and re-installing puts the problem back. We also do not have TortoiseGIT installed. We also see it is caused by TortoiseSVN because it only happens when you right-click on a file/folder that is inside a SVN working copy. Right-clicking on other files inside WSL does not cause the hanging.

Are there any traces we can make to investigate where the hanging is coming from?

Have you tried Sysinternals Process Monitor? Filtering on the Explorer.exe PID might show if Explorer is accessing storage or doing other "funny" things when you right-click. In this case, TortoiseSVN is running as a part of explorer.exe (loaded through the TortoiseSVN.DLL). It sounds awfully strange that TortoiseSVN would try to access storage after actually figuring out that the path should be excluded. But if you would see, through Process Monitor, that Explorer.exe is accessing files within the .svn folder then we have some kind of evidence that the filtering doesn't work.

Kind regards,

Daniel

[Johan Laneau]

Hi Daniel,

Thanks for the help in the investigation. I configured TortoiseSVN to exclude wsl paths as below:

Then I ran sys internals while right clicking on a folder inside a working copy of WSL. I can see that "explorer.exe" is accessing the .svn db. It appears to try to get a lock of the DB but this fails because WSL file system does not allow locking. Explorer appears to try to get a lock around 400times during 15seconds. This matches with the duration of the "hanging" in explorer. I attach the log of process explorer to this email. Does this help you debug the issue?

Kind regards,

Johan Laneau

To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/8313b6d9-7123-458d-b56c-566523076cbbn%40googlegroups.com.

[Daniel Sahlberg]

måndag 16 september 2024 kl. 17:19:35 UTC+2 skrev johan....@gmail.com:

Hi Daniel,

Thanks for the help in the investigation. I configured TortoiseSVN to exclude wsl paths as below:

Then I ran sys internals while right clicking on a folder inside a working copy of WSL. I can see that "explorer.exe" is accessing the .svn db. It appears to try to get a lock of the DB but this fails because WSL file system does not allow locking. Explorer appears to try to get a lock around 400times during 15seconds. This matches with the duration of the "hanging" in explorer. I attach the log of process explorer to this email. Does this help you debug the issue?

Thanks for checking. I was able to find the place in the code where TortoiseSVN is checking for wc.db. I think it is unreasonable to do it so I've proposed a change in the tortoise-dev group. Thanks for your patience while we look at this.

Kind regards,

Daniel

[Johan Laneau]

Thanks Daniel, we are looking forward to a fix!

To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/e80bd037-e17f-41a8-936c-247ff195d7c5n%40googlegroups.com.

[Daniel Sahlberg]

tisdag 17 september 2024 kl. 08:22:14 UTC+2 skrev johan....@gmail.com:

Thanks Daniel, we are looking forward to a fix!

I've just committed a fix in r29712. Can you please download the nightly build tomorrow (dated 19th) to check if it resolves the issue for you?

https://nightlybuilds.tortoisesvn.net/latest/x64/full/

Please note that the nightly builds don't support the new context menu (for Windows 11) so you need to hold down shift while right clicking (or select Show more options) to get the classic context menu. Both should exhibit the same problem.

Kind regards,

Daniel

[Johan Laneau]

Hi Daniel,

I tested with TortoiseSVN-1.14.99.29713-dev-x64-svn-1.14.dev.msi and the issue is indeed resolved. Thanks a lot for the quick fix!! Much appreciated for this nice support :-)

Do you have any idea when a formal release will be available with this fix included? Or is it OK for us to start using the nightly build?

Johan

To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/eaadf1d5-267a-4789-8f93-8e0077dce63cn%40googlegroups.com.

[Stefan]

On Thursday, September 19, 2024 at 1:02:01 PM UTC+2 johan....@gmail.com wrote:

Hi Daniel,

I tested with TortoiseSVN-1.14.99.29713-dev-x64-svn-1.14.dev.msi and the issue is indeed resolved. Thanks a lot for the quick fix!! Much appreciated for this nice support :-)

Do you have any idea when a formal release will be available with this fix included? Or is it OK for us to start using the nightly build?

 there is a new svn release in planing right now. So without promising anything, I think a new release of TSVN should be available in a few weeks.

However you can of course use the nightly build(s) if you like, they're stable too.

Stefan

[Daniel Sahlberg]

torsdag 19 september 2024 kl. 13:02:01 UTC+2 skrev johan....@gmail.com:

Hi Daniel,

I tested with TortoiseSVN-1.14.99.29713-dev-x64-svn-1.14.dev.msi and the issue is indeed resolved. Thanks a lot for the quick fix!! Much appreciated for this nice support :-)

Thank you for testing and for reporting back! Good to know the issue was resolved!

Kind regards,

Daniel