Can't open vscode offline in WSL when there is update

[hamza512b]

• VSCode Version: 1.49.3
• OS Version: wsl

Steps to Reproduce:

1. Make sure you are offline and don't have the lastest version of vscode
2. Open WSL (Windows Subsystem for linux)
3. run "code " to open vscode
4. Vsode will delete and try to update even if you are offline.

Does this issue occur when all extensions are disabled?: Yes

[hamza512b]

I been frustrated by this, because I don't have access to internet all the time. I end up using another editer.

[hamza512b]

This is what I am taking about:

❯ code .
Updating VS Code Server to version d2e414d9e4239a252d1ab117bd7067f125afd80a
Removing previous installation...
Installing VS Code Server for x64 (d2e414d9e4239a252d1ab117bd7067f125afd80a)
Downloading: 100%
Failed
Will not apply HSTS. The HSTS database must be a regular and non-world-writable file.
ERROR: could not open HSTS store at '/home/hamza/.wget-hsts'. HSTS will be disabled.
--2020-10-12 18:31:20--  https://update.code.visualstudio.com/commit:d2e414d9e4239a252d1ab117bd7067f125afd80a/server-linux-x64/stable
Resolving update.code.visualstudio.com (update.code.visualstudio.com)... failed: Temporary failure in name resolution.
wget: unable to resolve host address ‘update.code.visualstudio.com’
ERROR: Failed to download https://update.code.visualstudio.com/commit:d2e414d9e4239a252d1ab117bd7067f125afd80a/server-linux-x64/stable to /home/hamza/.vscode-server/bin/d2e414d9e4239a252d1ab117bd7067f125afd80a-1602520270.tar.gz

But sometimes it is different error too. Because sometimes it doesn't fully xdownload.

[gabrieledcjr]

any updates on this issue?

[pluma]

This makes VSCode unusable on spotty WiFi or if you have to restart VSCode for any reason after losing connection for an extended period of time (flight, outage, whatever). At this point I'm now considering leaving VSCode Remote for VSCode running in WSL itself just to avoid this problem.

I don't understand why it's not possible to have the old server continue to work with the new client for non-breaking releases. This seems like a design oversight given that client-server architectures normally don't use all-or-nothing versioning.

[Kif11]

tl:dr It seams like on what @aeschli mentioned at #5104 an update get triggered if vscode mismatch vscode server. Base on that fact a workaround could be disabling Auto Update in VSCode settings.

I definitely agree with @pluma and the fact that every new version is not compatible with previous version of WSL server make very little sense.

This quite unreasonable and painful behavior. To add a bit more details to this issue the problem is coming from bootstrap script wslDownload.sh

Here is the piece of code that remove the previous version.

	# This version does not exist
	if [ -d "$VSCODE_REMOTE_BIN" ]; then
		echo "Updating VS Code Server to version $COMMIT"

		# Remove the previous installations
		echo "Removing previous installation...";
		rm -rf "$VSCODE_REMOTE_BIN"/????????????????????????????????????????
		rm -rf "$VSCODE_REMOTE_BIN"/????????????????????????????????????????-??????????
		rm -rf "$VSCODE_REMOTE_BIN"/????????????????????????????????????????-??????????.tar.gz
	fi

I guess one solution could be is to check for internet connection before removing. However it seam unsound to do it in this download script. I'm trying to understand what trigger VSCode to update in the first place in case user is offline. I think, it would make most sense to do offline check before triggering the update procedure and just fall back to the installed version of VSCode server.

[pluma]

Would it be possible to prevent VSCode from auto-updating when exited while offline, if the remote extension is installed?

[pluma]

I could also imagine VSCode's auto-update having a notification like "A new version of VSCode has been downloaded in the background. VSCode will be updated the next time you exit the application" with a button for preventing that. Or at least a flag to prevent the auto-update while offline.

[buddudevelopers]

sible to have the old server continue to work with the new client for non-breaking releases. This seems like a design oversight given that client-server architectures normally don't use all-or-nothing versioning

I use wsl with visual studio it still does the very same thing