search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
162.16k stars 28.53k forks source link

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

Closed yerzhant closed 5 years ago

yerzhant commented 5 years ago

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 (c6e592b2b5770e40a98cb9c2715a8ef89aec3d74, 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 commented 5 years ago

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

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

Furqan136 commented 5 years ago

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

340rahul commented 5 years ago

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 commented 5 years ago

I think this will be solved by #64392 .

joaopauloufal commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Tyriar commented 5 years ago

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

mchameddie commented 5 years ago

Same issue and environment here as with joaopauloufal.

tomnieuwland commented 5 years ago

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 commented 5 years ago

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

Waiting for fix.

joaomoreno commented 5 years ago

Very likely broken by https://github.com/Microsoft/vscode/pull/63716

Kedstar99 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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: https://github.com/snapcrafters/vscode/issues/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 commented 5 years ago

@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/ 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.