Linux: ENOENT: no such file or directory, lstat '/snap/code'

[yerzhant]

Issue Type: Bug

Today after the Code has been updated to 1.30 I've started to receive the message:
ENOENT: no such file or directory, lstat '/snap/code'
on every start of the VS Code.
On the previous version, which was 1.29.1, there wasn't that issue.

Ubuntu 18.04
Linux azan-dev 4.15.0-42-generic #45-Ubuntu SMP Thu Nov 15 19:32:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Regards,
Yerzhan.

VS Code version: Code 1.30.0 (c6e592b, 2018-12-11T22:21:33.585Z)
OS version: Linux x64 4.15.0-42-generic

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz (4 x 3500)
GPU Status	2d_canvas: unavailable_software checker_imaging: disabled_off flash_3d: unavailable_software flash_stage3d: unavailable_software flash_stage3d_baseline: unavailable_software gpu_compositing: unavailable_software multiple_raster_threads: enabled_on native_gpu_memory_buffers: disabled_software rasterization: unavailable_software video_decode: unavailable_software video_encode: unavailable_software webgl: enabled_readback webgl2: unavailable_off
Load (avg)	2, 2, 2
Memory (System)	15.10GB (10.08GB free)
Process Argv	.
Screen Reader	no
VM	0%

Extensions (5)

Extension	Author (truncated)	Version
vscode-eslint	dba	1.7.2
beautify	Hoo	1.4.7
vscode-scss	mrm	0.6.2
vetur	oct	0.14.3
vuetify-vscode	vue	0.2.0

[vsimon]

Just hit this same bug. Same OS & version as OP.

'/snap/code' doesn't exist, but '/snap/vscode' does FWIW.

[Furqan136]

Same issue with KDE Neon 5.14 and it started with vscode version 1.30.0 just like it happened with you.

[340rahul]

Facing this issue as well. My OS version is Ubuntu 16.04 and vscode version is 1.30.0. I have /snap/vscode folder but not /snap/code.

[meddario]

I think this will be solved by #64392 .

[joaopauloufal]

Same issue with Ubuntu 18.04 LTS. VScode 1.30.0 installed from the Snap is fetching from a wrong directory when searching for updates (it should be '/snap/vscode' and not '/snap/code').

[DanGitOnline]

I don't know the fix, but I made a 'code' and 'current' sub-folder. Maybe it'll stop complainin' for the time being.

[Tyriar]

@flexiondotorg looks like there's an issue breaking v1.30 in https://snapcraft.io/vscode

[Tyriar]

In the meantime you can install the deb package from the website, note that the snap package is currently still experimental.

[mchameddie]

Same issue and environment here as with joaopauloufal.

[tomnieuwland]

Alternatively you can just use sudo snap revert vscode if you don't have any issues with using VSCode 1.29 for a little bit

[erakli]

For now, sudo ln -s /snap/vscode /snap/code did the trick.

Waiting for fix.

[joaomoreno]

Very likely broken by #63716

[Kedstar99]

@joaomoreno
Can you kindly take a look at the patch first.

These are the environment variables loaded within vscode. People can verify them by running printenv in the console within vscode.

SNAP_USER_DATA=/home/kd913/snap/vscode/72
SNAP_REVISION=72
SNAP_ARCH=amd64
SNAP_INSTANCE_KEY=
SNAP_USER_COMMON=/home/kd913/snap/vscode/common
SNAP=/snap/vscode/72
SNAP_COMMON=/var/snap/vscode/common
SNAP_NAME=vscode
SNAP_INSTANCE_NAME=vscode
SNAP_DATA=/var/snap/vscode/72
SNAP_COOKIE=NndxyyQKsPjkWB46Hr4dx4mVwmnP3bF3sBmMWKpHqlkP
SNAP_REEXEC=
SNAP_CONTEXT=NndxyyQKsPjkWB46Hr4dx4mVwmnP3bF3sBmMWKpHqlkP
SNAP_VERSION=1.30.0-1544567151
SNAP_LIBRARY_PATH=/var/lib/snapd/lib/gl:/var/lib/snapd/lib/gl32:/var/lib/snapd/void

These environment variables are set by snapd not vscode. These variables are listed here:
https://github.com/snapcore/snapd/wiki/Environment-Variables

In this case the environment variable SNAP is guaranteed to be a valid path. If these environment variables are invalid then the entire class should be restructured as they currently rely on the environment variables being set.

People can alternatively try using the following command to run a shell within the vscode snap to verify the above to prove that these environment variables aren't being set or modified by vscode.

snap run --shell vscode

Key thing here is the the environment variable is loading /snap/vscode not /snap/code which people are having issues with here. None of the environment variables are set as /snap/code. In #63716 I removed a hardcoded path to /snap/code.

The problem in this case is that my PR #64392 isn't merged.

The isUpdateAvailable method within snapUpdateService is looking as this.
realpath(/snap/${product.applicationName}/current, (err, resolvedCurrentSnapPath) => {

Where product.applicationName is set as code. My pr changes this to use the environment variable instead. This function at present is what is causing this bug as /snap/code/current doesn't exist.

Running this command:

/snap/vscode/current/usr/share/code/resources/app$ cat product.json | grep 'application'
"applicationName": "code",

The reason this is set like this is because at present the snapcraft version of vscode is built against the Linux Deb. It just names and mounts the Deb under the name vscode.

Everyone here can look and run these commands themselves. Please, try PR 64392 before reverting my other one.

I am 100% confident that this is the cause of this issue as that function is the only reference to /snap/code.

[joaomoreno]

@Kedstar99 The vscode snap is a community driven snap package. The updateService.snap.ts functionality isn't meant for that package, but for us to officially ship a snap package ourselves.

I've merged #64392 which fixes this issue and added a check for snapUpdate.sh to make sure we stick to our focus.

[jackTaw88]

@Kedstar99 SNAP dos not guaranteed to be a valid path, if snap is under classic confinement. read here:

https://github.com/snapcore/snapd/wiki/Environment-Variables#home

I had open a bug for snapcrafters here:
snapcrafters/vscode#36

The $HOME directory is wrong.

The same problem exist for Atom text editor. I don't think this is a problem about electron based apps. Because insomnia (http client) app is electron based and does not have the same problem.

[Kedstar99]

@jackTaw88 The code is using $SNAP which is always mounted in /snap/. This is especially true for classic confined snaps which won't install unless mounted in /snap. I don't know why you are saying that SNAP isn't always a valid path. It isn't a valid path basically if you mess up and try and move the snap manually which isn't a supported mechanism as far as i am aware.

The SquashFS system will always mount the SNAP in /snap/<snap_name> for easy, predictable and deterministic behaviour.

https://docs.snapcraft.io/the-snap-format/698

I don't know why you are talking about the $HOME directory as that variable isn't being used here. Even so, you are wrong in saying the $HOME directory is incorrect. As the snap is installed under classic confinement, it should have unrestricted access to the system. It is treated as equivalent to a install of a deb with no restrictions. A developer environment/IDE which can't open certain files, or open certain programs is pretty pointless.

The documentation you linked even states this.

Since snapd 2.20 the HOME variable is not re-written when snap is under classic confinement.

The SNAP environment variables listed above are listed for vscode under classic confinement.

Also, using the environment variables is a lot safer than hardcoding paths.