Cannot install rust-analyzer binary if an instance of vscode is already running on Windows

[yoshuawuyts]

Problem

Following up on #3092: I think I figured out what was causing EBUSY (in some cases)!

So I was prompted with installing the rust-analyzer binary again today, and it kept on failing with EBUSY. It then dawned on me: I already had a few VS Code instances open, so could that be what kept it busy? I tried it 4 times, and was prompted with EBUSY each time.

I then closed all running VS Code instances, opened a new instance, and suddenly downloading and installation worked! So I think it's fair to conclude: if VS Code is already running and already using the location the binary would be written to, installation will fail.

Solution

I'm not sure what the solution here is, but there seems to be a general issue around downloading a file into a location that's already in use. Perhaps the solution is to use version the binary name. Perhaps something using fd locks could work? I'm not a Windows expert so I can't say for sure, but a solution is probably in that corner.

---

Anyway, I hope this is helpful! I ran into this by accident when updating today, and am kind of thrilled that I managed to make it fail reliably!

[matklad]

Yeah, I guess what might do is:

1. add release name to binary name

2. schedule old binaries for deletion on the next reboot

3. is pretty windows specific though... I wonder if the better solution is to implement some kind of "which version of rust-analyzer do you want to use" functionality, where we just keep a list of recently installed binaries. I am not too excited about going into that direction though, as I would prefer to keep the amount of features and logic in front-end to the absolute minimum.

Curious what folks with more windows experience thing about this? Note that on linux you can just overwrite binary of a running program, which makes such updates seamless without any explicit handing.

[matklad]

Hm, perhaps we should have just two binaries "rust-analyzer", and "rust-analyzer.next", and let the extension to try replace ra with ra.next on startup?

[yoshuawuyts]

@matklad Whatever solution is settled on, I agree that we shouldn't expose more choices to end-users; people really appreciate it when updates just work. To that extent the current "download new rust-analyzer binary" might already be too much interaction.

[matklad]

To that extent the current "download new rust-analyzer binary" might already be too much interaction.

Agree with that, but I also think that we shouldn't do http requests without explicit user's action, so I probably don't want to just silently download stuff.

[Veetaha]

What about:

{
    "rust-analyzer.alwaysDownloadThatBinaryNeverAskMeAgain": true
}

Anyway, we could just handle that EBUSY prank and explicitly ask to close any other extension processes.
I also don't like the idea of allowing to choose the version of the lsp binary, since it might be incompatible with the extension version!
Storing all the binaries under different names could do the trick, but as they say, it's better not to leave trash in the first place...
Also, if I am not mistaken, I didn't see that any other extension code that handled this situation, though it doesn't relieve us from doing so!

[Veetaha]

And, regarding #3092 that EBUSY was a different kind of EBUSY anyway...

[ivan]

I noticed that with rust-analyzer 0.2.117 on Windows + Remote SSH to Linux, I no longer get the EBUSY popup notification, it just silently fails when trying to download the binary. I keep vscode running on multiple machines that are sometimes out of reach, so my "get the thing to upgrade" workaround has been to run this on the Linux machine and then ctrl-c out after the launch retries stop:

while true; do killall rust-analyzer-linux; done

[Veykril]

No longer relevant