Failed to download: EPERM: operation not permitted

[strowk]

When I start VSCode it shows me a message that I need to install rust analyzer language server. I click download button and then following error is shown:

Failed to download: EPERM: operation not permitted, unlink 'c:\Users\myuser\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-windows.exe'

I'm using Windows 10, VSCode 1.51.1, extension Rust Analyzer v0.2.384

[lnicola]

That can happen if the language server is running multiple times (if you have more than one Code open or if an older rust-analyzer instance got stuck and didn't close).

[lnicola]

Do you still have this issue?

[lnicola]

Closing since there's not much to do here: we understand the cause (the server is already running), but there's nothing actionable.

@strowk please reopen if it stil happens with a single Code instance running or if you find other steps to reproduce it.

[strowk]

I don't have that issue anymore (I stopped using rust-analyzer)

[Livven]

@lnicola

[...], but there's nothing actionable.

What about keeping old rust-analyzer-windows.exe files around and downloading to a different path instead? Old versions could be cleaned up afterwards. This would enable analyzer updates even if an existing instance is running.

[lnicola]

@Livven we could do that, but it's not trivial:

• we need to keep generating new (probably random) filenames, since the user might have more than two open instances
• on restart, we won't necessarily know which of the new versions is the good one, so we'll have to run each of them to check the version or try to download the server again
• if the server crashes, we need to make sure to restart the same version, regardless of the name
  • there's even a slight window here where the user might start a new Code instance right after it crashed, so the server might not even exist any more
• auto-updating is not the easiest functionality to test and I already broke it a couple of times :-)

A PR for this would probably be welcome, though.

[lnicola]

I think there might be another open issue for this but I can't find it right now, let's reopen it since it's something that people seem to really care about.

[Livven]

Thanks, I'll see if I can find the time and come up with something. I ran into a similar EPERM issue but with the offender being a rename. Don't remember the details, think it might be a slightly different problem but was too lazy to open a new issue.

[martin-t]

Has anybody tried renaming the old executable instead of deleting it and putting the new one in its place? I am told it's not possible to rename running executables but i remember doing exactly that in an updater for an app a wrote a long time ago.

[lnicola]

What happens if running Code instance tries to restart the language server (because it crashes or the user requested it)?

If we add a version string to the server executable name we can avoid most of these issues.

[lnicola]

Heads-up: #9585 just landed and should help with this, but not in every case: if you're running two Code instances, update the server from one of them, then restart or crash the server in the other one, it will use the new server version with the old extension, which can sometimes cause problems.

[lnicola]

Update: since #11053, the server binary is bundled with the extension, and (assuming Code handles updates nicely), no longer updated while running. So this is finally fixed for good.