Steps to Reproduce:
This use to work, now I get the following error message:
Failed to move 'app.component.css' to the trash
I am then asked each time to click on the "Delete Permanently" button to actually delete the file?
@rajinder-yadav this indicates that the folder you have opened is maybe not able to move to trash, this can happen if the folder is from a network drive for example or you need other permissions to do so. Does it reproduce with any folder you open?
There are 2 places I work from, my home folder or under /tmp in both cases I had no issues about deleting files. I just notice this problem the other day, I even tried restarting vscode, then I emptied my trash just to make sure it was not full. The problem persisted.
I don't know what caused it, it happen once so far. I just created a new project and was able to delete files, so I am not sure how to repro it yet, just that it happened and would not go away.
@rajinder-yadav and can you move to trash if you use the windows explorer?
It's on Linux, and yes I can move files to from trash using the file explorer, both locations have global read/write permission.
Ah sorry, didn't see this was linux. Looks like an upstream electron issue then, we just call into their function. If you can reproduce using Atom, I suggest filing a bug against them.
I don't have a trash. Is there any chance of a configuration option to change 'Delete file' to unconditionally remove the file moving trying to move it to the trash?
@davidgiven you can hold the Shift key and delete to bypass trash anytime.
Delete issue on Linux resolved for me. found this:
https://code.visualstudio.com/docs/setup/linux#_debian-and-moving-files-to-trash
One annoying thing, please add a setting to stop making me confirm the delete.
@rajinder-yadav I've tried that on ubuntu 16.10 but it didn't worked. What distro are you using?
@marcelopm Kubuntu 16.10
This workaround seems to partially solve the issue:
sudo mkdir /.Trash-1000
sudo chown user:user /.Trash-1000
ref: https://github.com/atom/tree-view/issues/=345#issuecomment-125778929
But now I have two trashcans, which is quite annoying specially because one is integrated to my desktop manager and the other is not.
BTW soft-linking it to ~/.local/share/Trash doesn't work neither does mount bind: sudo mount -o rbind /home/user/.local/share/Trash /.Trash-1000
@bpasero going to open a new feature request to request silencing of getting nagged "are you sure" each time I want to delete a file.
@marcelopm you're going to forget to empty one of those trash can now, I would not recommend this solution. It actually creates a new problem!
:+1:
@marcelopm the workaround of create a directory _/.Trash-1000_ worked for me
+1 to solve this bug
This issue was fixed by sudo apt-get install gvfs-bin
on my old Lubuntu machine.
But I would +1 for a flag to kill the popup window asking if I really want to put the file in trash. I don't need to be reminded that I can restore files from trash. For a permanent delete this question might be relevant though. But still.. If I permanently delete a file by mistake I can always restore it from git, so even in that case the question is a little bit too "nanny" for me. ;-)
Ubuntu:
Distributor ID: Ubuntu
Description: Ubuntu 16.04.2 LTS
Release: 16.04
Codename: xenial
Visual Studio Code:
Version 1.12.2
Commit 19222cdc84ce72202478ba1cec5cb557b71163de
Date 2017-05-10T13:16:25.899Z
Shell 1.6.6
Renderer 56.0.2924.87
Node 7.4.0
Still facing this issue.
Still happening in 1.14.2, still an everyday annoyance...
(Vscode shouldn't be assuming that a trash exists, or exists in a particular place --- they're not universal on Linux. This really needs to be configurable.)
having the same issue on macos 10.13.2 and vscode 1.19.1
This also happens to me. Fedora 26 and vscode 1.19.1
Also on Arch in the last month or so
I noticed that moving to the trash doesn't work if I have launched editor from terminal using code .
If I use icon from launcher and open folder manually, it works fine.
code --version
1.20.0
c63189deaa8e620f650cc28792b8f5f3363f2c5b
x64
Ubuntu 17.10
It's the same for me. If I run from a terminal (which is what I do 99.5% of the time) sending files to Trash does not work. If VS Code has been launched from the desktop launcher it works.
Someone earlier said this is an electron issue but it's not. Atom has no problem sending files to the Trash.
This is on Ubuntu 17.10, VS Code 1.20.1.
Can confirm. Using arch linux and vscode 1.20.1. Doesn't work if ran from shell, does work if launched from desktop.
Can't confirm about launching it from desktop because I don't use any desktop environment.
But gvfs is installed and working.
Frank
Trash stopped working on vscode started from shell after upgrade to 1.20.1. Ubuntu 17.10.
1.20.1
f88bbf9137d24d36d968ea6b2911786bfe103002
x64
Trash works if I run with --wait
; otherwise it doesn't.
$ code --version
1.20.1
f88bbf9137d24d36d968ea6b2911786bfe103002
x64
Same here, on linux too. If I delete a file from native file explorer, it goes to trash like expected.
If I delete using vscode, I always have the prompt:
(even with "explorer.confirmDelete": false
) and pressing delete permanently doesn't move it to trash.
A Direct delete that goes in trash is actually much safer than a prompt for this no-trash delete.
(shift
-delete
works directly too, but without the trashing it's super unsafe)
So the current way is more annoying, and less safe.
I don"t really want to create those .Trash-1000
local folders per project too
It's an electron issue as it appears?
edit I've an older laptop, same OS, where the deletion from vscode works fine, like native file explorer, and deleted files go in trash. Need to figure out, both vscode have same settings
Oh I think it's what @mgolebiowski said, the older laptop has an older version of vscode, upgrading to latest to check
@bpasero Yes confirmed:
As of version
1.20.1
f88bbf9137d24d36d968ea6b2911786bfe103002
x64
vscode is not able to send files to trash anymore, when deleting (when launching vscode from terminal: code .
, as @kdar points out, it still works if launched from desktop)
Same issue
Ubuntu 17.10
1.20.1
f88bbf9137d24d36d968ea6b2911786bfe103002
x64
And also only happens when I run VSC from terminal code .
See this pull request: https://github.com/electron/electron/pull/7178
In my case (Antergos Linux, which is Arch based), the problem is that the gvfs
has been deprecated in favor of gio
.
So, if I set the following environment variable before launching VSCode, it works: ELECTRON_TRASH=gio
.
Note that gio
backend was added later than the original pull request I mentioned earlier.
Probably at some point the default will change from gvfs
to gio
, but until then, the workaround works.
On Fedora 27, added ELECTRON_TRASH=gio
to my .bashrc
problem fixed.
Same issue with redhat 7.4. Manually calling gvfs-trash on a file works okay but not from within vs code or indeed atom. Happens when launching from desktop or command line. Switching to gio appears to fix it though.
Working on Debian, with my data stored in a separate partition.
I have created a /.Trash folder manually as described in the XDG specifications, deleting files from Nautilus creates a subfolder /.Trash/1000 (as it should according to the specs); however VS Code still doesn't know how to trash my files. Setting ELECTRON_TRASH=gio
does work here.
@brad-jones i've added that, but still not working.
but ELECTRON_TRASH=gio code .
works.
Ubuntu 17.10
Has anyone looked at why launching from terminal behaves differently? Why does it use wrong driver in one case but not in other?
Still broken in Ubuntu 18.04, with gvfs-bin
already installed.
Problem only when launching via code .
Still broken with latest release and gvfs-bin
installed.
code --version
1.25.0
0f080e5267e829de46638128001aeb7ca2d6d50e
x64
deleting file works perfectly fine if I open it from the desktop launcher instead of a terminal. I'm using ubuntu 18.04.
I fixed this problem by installing the .deb available through the official downloads page NOT the Visual Studio Code application available by default in the Ubuntu Software Center.
I did the same, but in my case it didn't work. Perhaps some files
remained... Only using the launcher solves my problem for now.
I use .debs from downloads page and the problem occurs anyways.
For now the always working fix is exporting ELECTRON_TRASH=gio
before running $ code
command as @brad-jones proposed.
A workaround until this bug is fixed:
bash
sudo mv /usr/bin/code /usr/bin/codeReal
sudo sh -c "echo 'ELECTRON_TRASH=gio codeReal \$1' >> /usr/bin/code"
sudo chmod 777 /usr/bin/code # same permissions as original
Then use code .
as usual.
(Works for me with Ubuntu 18.04.1 LTS and vscode 1.25.1)
Added ELECTRON_TRASH=gio
into the file _~/.bashrc_, to make it permanent. Now moving to the trash works when launching by code .
But not if I directly launch vscode through the ubuntu dash/dock/ubuntu software or by right click on the folder > open with the application vscode
Ubuntu 18.04.1 LTS
VSCode 1.125.1
@manuel-di-iorio Try adding export ELECTRON_TRASH=gio
to either ~/.profile
or in a file in /etc/profile.d/
instead. That should make it work when launching from a GUI after you log out and log back in.
@kramerc it worked by adding the line into the ~/.profile
file, thank you so much
Fyi there is now (tomorrows insider build) a setting files.enableTrash
to disable the usage of the trash when deleting in case someone really cannot or does not want to use the trash (ref: https://github.com/Microsoft/vscode/issues/14638#issuecomment-420578375)
FYI: Electron 3 fixes this, it replaces the usage of the deprecated gvfs-trash
by gio
instead as fallback (part of glib2) if it can't determine the Desktop Environment.
source
Closing this issue given that we plan to release VSCode stable early February with Electron 3.x. If you want to benefit from the fix already, consider to use our insiders version that already contains the fix: https://code.visualstudio.com/insiders/
For what it's worth the ELECTRON_TRASH=gio
workaround didn't work for for me on Ubuntu 16.04, but ELECTRON_TRASH=gvfs-trash
does. Perhaps the gio
approach doesn't work on Ubuntu 16.04.
code --version
1.31.1
1b8e8302e405050205e69b59abb3559592bb9e60
x64
Most helpful comment
On Fedora 27, added
ELECTRON_TRASH=gio
to my.bashrc
problem fixed.