Unable to delete files on Fedora 28 (gvfs-trash is deprecated)

[Devligue]

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
  • Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
  • Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
  • Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
  • Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

My issue is the same as in #15949 except it is not fixed.

I am unable to delete file (or directory). When trying, the following message appears: Is gvfs-trash installed?

Steps to Reproduce

1. Try to delete any file or directory
2. ???
3. Profit

Expected behavior: Deleting file should delete file

Actual behavior: The file is not deleted

Reproduces how often: Every time

Versions

Atom    : 1.27.1
Electron: 1.7.15
Chrome  : 58.0.3029.110
Node    : 7.9.0

apm  1.19.0
npm  3.10.10
node 6.9.5 x64
atom 1.27.1
python 2.7.15
git 2.17.1

OS: Fedora 28

Additional Information

$ gvfs-trash
This tool has been deprecated, use 'gio trash' instead.
See 'gio help trash' for more info.

The gio trash is supposedly implemented since electron 1.7.2 and for some folks out there this problem was fixed with Atom 1.25 (which included upgrade to Electron 1.7.11) but apparently I am on even newer Atom version, with even newer Electron and it still happens.

EDIT1

More insight on the problem provided by @cutephoton:

@Devligue This is a legit bug. The tldr answer is that _g_file_trash may not be supported. In order for _g_file_trash to succeed, the following conditions must be met:

• The file being moved to trash is on the same partition as your home folder
  OR
• A trash folder already exists or can be created at the mount point and,
• The trash folder is considered 'safe/secure' by verifying UID and restrictive permissions

How this should probably be fixed...

Atom does not have a fallback mechanism like offering the ability to permanently remove a file instead. This would address bring atom in line with gnome's graceful behaviour. The attached image show how Gnome Files (aka Nautilus) prompt the user to permanently delete the file (when trash not supported)

Impact: Users with multiple disks and partitions

Fedora/Redhat/etc: Impacted due to default partition scheme that separates / and /home in to partitions. Files outside of the /home partition cannot be moved to trash.

Ubuntu: Less likely due to partition layout (/home is part of the / partition)

Conditions where users will be impacted:

• File systems with unix permissions:

  • Impacted with workaround due to typical restrictive top-level directory permissions (root)

• FAT/non-unix file systems:

  • User Session Mount (i.e. /run/media/$USER/disk-label): No Impact
  • Fstab: Impacted even with permissive umask. The default uid/gid is root. It will be unable to satisfy the requirements of a trash folder without additional options (uid/gid/umask).

• Network shared folders: Unknown/Did not test.

Notes/Testing the Root Cause

Note: Though I am confident that my analysis is decent enough, much of the code I was referencing was unfamiliar/new to me.

Initially I encountered this issue when I put files in a certain location like the reporter above. I created a delete-me file test as suggested above in the relevant directory, /opt/cupenv. I ran the command strace gio trash delete-me.txt. A abridged version of the output is here:

lstat("/opt/cupenv/delete-me.txt", {st_mode=S_IFREG|0664, st_size=6, ...}) = 0
...
lstat("/.Trash-1000", 0x7ffde5ffb5b0)   = -1 ENOENT (No such file or directory)
mkdir("/.Trash-1000", 0700)             = -1 EACCES (Permission denied)

That's unexpected. The API documentation for g_file_trash lacks some level of specificity.

Sends file to the "Trashcan", if possible. This is similar to deleting it, but the user can recover it before emptying the trashcan. Not all file systems support trashing, so this call can return the G_IO_ERROR_NOT_SUPPORTED error.

One might assume (as I did): Given a path, if the user has permission to modify/delete the file, then GIO's g_file_trash API should succeed at removing the file in some manner. Perhaps, if trash functionality is not available, then there might be a fallback mechanism. In the case of gio trash I expected there to be a -f force option that would prioritize trash over permanently deleting the file. (gio trash -f only ignores files that don't exist)

Glib appears to implement GIO local file access using glocalfile.c. The trash algorithm looks like this:

• Is the path on the same partition as the user's home directory? If so, move the file to the home trash folder if possible and exit.

• Given the path, locate the mount point top level directory (denoted as $topdir in source)

  • In my case, /opt/cupenv/delete_me.txt -> / (the primary partition)
  • A more typical case: /run/media/$USER/disk-label/a/b/c/d would be /run/media/$USER/disk-label

• If $topdir is found, pick one of $topdir/.Trash/$UID or $topdir/.Trash-UID folder.

  • If $topdir/.Trash-UID and $topdir/.Trash/$UID exists: Validate proper UID and file permission (or fail)
  • Try to create folder $topdir/.Trash-$UID. Validate proper UID and file permission (or fail)

At the end of the function we find G_IO_ERROR_NOT_SUPPORTED is returned when such a folder is not found and cannot be created.

if (trashdir == NULL)
	{
	  g_free (topdir);
          g_set_io_error (error,
                          _("Unable to find or create trash directory for %s"),
                          file, G_IO_ERROR_NOT_SUPPORTED);
	  return FALSE;
}

I confirmed my understanding by creating a top level trash folder and using gio trash command.

sudo mkdir /.Trash-1000
sudo chmod 0700 /.Trash-1000
sudo chown fosterb:fosterb /.Trash-1000
cd /opt/cupenv && echo hello > delete-me.txt; gio trash delete-me.txt

Files located on the same partition as your home directory can always be moved to your user trash folder. On my operating system, the paths / and /home are separate partitions. I created a file /home/tmp/x where tmp and x are owned by my user. In this case, the files get moved to your $HOME/.local/share/Trash folder.

lstat("/home/tmp/x", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
stat("/home/fosterb", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
access("/home", F_OK)                   = 0
....
stat("/home/fosterb/.local/share", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access("/home/fosterb/.local/share/Trash", F_OK) = 0
stat("/home/fosterb/.local/share/Trash", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
mkdir("/home/fosterb/.local/share/Trash/info", 0700) = -1 EEXIST (File exists)
mkdir("/home/fosterb/.local/share/Trash/files", 0700) = -1 EEXIST (File exists)
openat(AT_FDCWD, "/home/fosterb/.local/share/Trash/info/x.trashinfo", O_RDONLY|O_CREAT|O_EXCL, 0666) = 7

But when mounting disks (external or internal) using fstab or mount commands (as opposed to session-based mounting) issues can arise. I tested a FAT file system with umask=0000 and uid/gid set to root.

lstat("/mnt/giotest", {st_mode=S_IFDIR|0777, st_size=8192, ...}) = 0
lstat("/mnt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/mnt/giotest/.Trash", 0x7fffec5502c0) = -1 ENOENT (No such file or directory)
lstat("/mnt/giotest/.Trash-1000", 0x7fffec550230) = -1 ENOENT (No such file or directory)
mkdir("/mnt/giotest/.Trash-1000", 0700) = 0
lstat("/mnt/giotest/.Trash-1000", {st_mode=S_IFDIR|0777, st_size=8192, ...}) = 0
unlink("/mnt/giotest/.Trash-1000")      = -1 EISDIR (Is a directory)
rmdir("/mnt/giotest/.Trash-1000")       = 0
file:///mnt/giotest/x: Unable to find or create trash directory for /mnt/giotest/x

You can see gio trash going through the motions. The operations succeeds but the command still reports an error.

[fosterb@rose giotest]$ ls -lah
total 12K
drwxrwxrwx. 2 root root 8.0K Aug  1 00:36 .
drwxr-xr-x. 4 root root 4.0K Aug  1 00:30 ..
-rwxrwxrwx. 1 root root    0 Aug  1 01:23 x

GLib/Gio will not write to a trash directory with incorrect permissions/ownership. (Security?) Without unix permissions, trash will always fail on these mount points. Modifying fstab to appear similar to options used during session mounts (UID/GID set to user vs root, umask is set appropriately). Conveniently the source code has a comment that seems to strongly imply this is a known/expected.

		  /* Ensure that the created dir has the right uid etc.
		     This might fail on e.g. a FAT dir */

Most of this was unnecessary, but I figured I'd show my work.

EDIT2

More insight, to not get confused as of the nature of the bug, and how to reproduce it (by @cutephoton as well):

Yes, as reported, the ELECTRON_TRASH environment variable is needed. This is the issue referenced #15949 bug. The issue reported here is not related to #15949. The error message related to gvfs-trash is a blunt tool (even access denied errors produce the same error message) so I understand why people are responding here.

The reporter clarifies one of the key symptoms here:
#17452 (comment)

And that led to my deep dive. My deep dive details the specific cases where trash becomes unavailable (i.e. when a trash folder cannot be safely created).
#17452 (comment)

I just revalidated my findings and unsurprisingly gio trash still fails.

Anyhow, I wanted to clarify this so it doesn't get lost when/if atom devs look in to this issue.

[rsese]

Thanks for opening a new issue - is gio available on Fedora 28?

[Devligue]

Yes, gio is available and installed by default

[rsese]

Hmmm, not sure why it's not working then - any difference if you specifically set an ELECTRON_TRASH environment variable to gio and then restart Atom?

[Devligue]

It changes nothing 🤔

$ gio --version
2.56.1

echo $ELECTRON_TRASH
gio

[rsese]

And if you just use gio trash from the command line it works fine? E.g.:

echo hello > delete-me.txt
gio trash delete-me.txt

Also, are you getting the exact same error message you mentioned ("When trying, the following message appears: Is gvfs-trash installed?") after you set the ELECTRON_TRASH environment variable to gio?

[Devligue]

The echo hello > delete-me.txt; gio trash delete-me.txt works just fine normally but crashes on the ntfs partition. As I see this, it is not an Atom bug, however the error message it kept returning me was quite misleading.

I didn't solve the problem yet, but I am closing this since it is not related to Atom. Sorry for trouble!

[50Wliu]

however the error message it kept returning me was quite misleading.

Yeah, that's the default error message. Unfortunately, Electron's moveToTrash method doesn't say why it failed, just that it did. We've found that the most common reason is that gvfs-trash isn't installed, which is why we decided to include it in the error message.

[cutephoton]

@Devligue This is a legit bug. The tldr answer is that _g_file_trash may not be supported. In order for _g_file_trash to succeed, the following conditions must be met:

• The file being moved to trash is on the same partition as your home folder
  OR
• A trash folder already exists or can be created at the mount point and,
• The trash folder is considered 'safe/secure' by verifying UID and restrictive permissions

How this should probably be fixed...

Atom does not have a fallback mechanism like offering the ability to permanently remove a file instead. This would address bring atom in line with gnome's graceful behaviour. The attached image show how Gnome Files (aka Nautilus) prompt the user to permanently delete the file (when trash not supported)

Impact: Users with multiple disks and partitions

Fedora/Redhat/etc: Impacted due to default partition scheme that separates / and /home in to partitions. Files outside of the /home partition cannot be moved to trash.

Ubuntu: Less likely due to partition layout (/home is part of the / partition)

Conditions where users will be impacted:

• File systems with unix permissions:
  • Impacted with workaround due to typical restrictive top-level directory permissions (root)
• FAT/non-unix file systems:
  • User Session Mount (i.e. /run/media/$USER/disk-label): No Impact
  • Fstab: Impacted even with permissive umask. The default uid/gid is root. It will be unable to satisfy the requirements of a trash folder without additional options (uid/gid/umask).
• Network shared folders: Unknown/Did not test.

Notes/Testing the Root Cause

Note: Though I am confident that my analysis is decent enough, much of the code I was referencing was unfamiliar/new to me.

Initially I encountered this issue when I put files in a certain location like the reporter above. I created a delete-me file test as suggested above in the relevant directory, /opt/cupenv. I ran the command strace gio trash delete-me.txt. A abridged version of the output is here:

lstat("/opt/cupenv/delete-me.txt", {st_mode=S_IFREG|0664, st_size=6, ...}) = 0
...
lstat("/.Trash-1000", 0x7ffde5ffb5b0)   = -1 ENOENT (No such file or directory)
mkdir("/.Trash-1000", 0700)             = -1 EACCES (Permission denied)

That's unexpected. The API documentation for g_file_trash lacks some level of specificity.

Sends file to the "Trashcan", if possible. This is similar to deleting it, but the user can recover it before emptying the trashcan. Not all file systems support trashing, so this call can return the G_IO_ERROR_NOT_SUPPORTED error.

One might assume (as I did): Given a path, if the user has permission to modify/delete the file, then GIO's g_file_trash API should succeed at removing the file in some manner. Perhaps, if trash functionality is not available, then there might be a fallback mechanism. In the case of gio trash I expected there to be a -f force option that would prioritize trash over permanently deleting the file. (gio trash -f only ignores files that don't exist)

Glib appears to implement GIO local file access using glocalfile.c. The trash algorithm looks like this:

• Is the path on the same partition as the user's home directory? If so, move the file to the home trash folder if possible and exit.
• Given the path, locate the mount point top level directory (denoted as $topdir in source)
  • In my case, /opt/cupenv/delete_me.txt -> / (the primary partition)
  • A more typical case: /run/media/$USER/disk-label/a/b/c/d would be /run/media/$USER/disk-label
• If $topdir is found, pick one of $topdir/.Trash/$UID or $topdir/.Trash-UID folder.
  • If $topdir/.Trash-UID and $topdir/.Trash/$UID exists: Validate proper UID and file permission (or fail)
  • Try to create folder $topdir/.Trash-$UID. Validate proper UID and file permission (or fail)

At the end of the function we find G_IO_ERROR_NOT_SUPPORTED is returned when such a folder is not found and cannot be created.

if (trashdir == NULL)
	{
	  g_free (topdir);
          g_set_io_error (error,
                          _("Unable to find or create trash directory for %s"),
                          file, G_IO_ERROR_NOT_SUPPORTED);
	  return FALSE;
}

I confirmed my understanding by creating a top level trash folder and using gio trash command.

sudo mkdir /.Trash-1000
sudo chmod 0700 /.Trash-1000
sudo chown fosterb:fosterb /.Trash-1000
cd /opt/cupenv && echo hello > delete-me.txt; gio trash delete-me.txt

Files located on the same partition as your home directory can always be moved to your user trash folder. On my operating system, the paths / and /home are separate partitions. I created a file /home/tmp/x where tmp and x are owned by my user. In this case, the files get moved to your $HOME/.local/share/Trash folder.

lstat("/home/tmp/x", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
stat("/home/fosterb", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
access("/home", F_OK)                   = 0
....
stat("/home/fosterb/.local/share", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access("/home/fosterb/.local/share/Trash", F_OK) = 0
stat("/home/fosterb/.local/share/Trash", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
mkdir("/home/fosterb/.local/share/Trash/info", 0700) = -1 EEXIST (File exists)
mkdir("/home/fosterb/.local/share/Trash/files", 0700) = -1 EEXIST (File exists)
openat(AT_FDCWD, "/home/fosterb/.local/share/Trash/info/x.trashinfo", O_RDONLY|O_CREAT|O_EXCL, 0666) = 7

But when mounting disks (external or internal) using fstab or mount commands (as opposed to session-based mounting) issues can arise. I tested a FAT file system with umask=0000 and uid/gid set to root.

lstat("/mnt/giotest", {st_mode=S_IFDIR|0777, st_size=8192, ...}) = 0
lstat("/mnt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/mnt/giotest/.Trash", 0x7fffec5502c0) = -1 ENOENT (No such file or directory)
lstat("/mnt/giotest/.Trash-1000", 0x7fffec550230) = -1 ENOENT (No such file or directory)
mkdir("/mnt/giotest/.Trash-1000", 0700) = 0
lstat("/mnt/giotest/.Trash-1000", {st_mode=S_IFDIR|0777, st_size=8192, ...}) = 0
unlink("/mnt/giotest/.Trash-1000")      = -1 EISDIR (Is a directory)
rmdir("/mnt/giotest/.Trash-1000")       = 0
file:///mnt/giotest/x: Unable to find or create trash directory for /mnt/giotest/x

You can see gio trash going through the motions. The operations succeeds but the command still reports an error.

[fosterb@rose giotest]$ ls -lah
total 12K
drwxrwxrwx. 2 root root 8.0K Aug  1 00:36 .
drwxr-xr-x. 4 root root 4.0K Aug  1 00:30 ..
-rwxrwxrwx. 1 root root    0 Aug  1 01:23 x

GLib/Gio will not write to a trash directory with incorrect permissions/ownership. (Security?) Without unix permissions, trash will always fail on these mount points. Modifying fstab to appear similar to options used during session mounts (UID/GID set to user vs root, umask is set appropriately). Conveniently the source code has a comment that seems to strongly imply this is a known/expected.

		  /* Ensure that the created dir has the right uid etc.
		     This might fail on e.g. a FAT dir */

Most of this was unnecessary, but I figured I'd show my work.

[yodatak]

I got the same problem on feodra 29 on a fresh install can we reopen this bug ?

[cutephoton]

@Devligue can reopen this

[no-response]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[Devligue]

I may have no additional information about the issue, but I am sure @cutephoton provided enough insight. There are also other people who have similar unsolved problems. I am reopening this.

[yodatak]

I got no problem with the flatpak version by the way

[cutephoton]

I reproduced on the latest version still. shrug I don't see how flatpak and rpm/deb would differ. It only fails when the preconditions listed above are met -- a partition where you don't have permission to create a trash folder under your user ID.

[yodatak]

With flatpak i got no error but it don't get delete sorry about this misinformation. I try to disable selinux it don't change.

[cutephoton]

No. Not selinux. It has to do with how trash folders work. My rather verbose explanation gets in to the nitty gritty for where atom's behavior is deficient. The short answer is that atom only asks to move files to trash and does not delete files. If a trash folder cannot be created (multiple causes all related to permissions) than it fails. Atom should inquire with user if they should permanently delete the files instead of failing.

[mkungla]

As @yodatak also mentioned that Fedora 29 fresh install has this problem since gvfs-trash has finally after many deprecation notices been removed and replaced with gio. So as @rsese mentioned you need to set ELECTRON_TRASH=gio e.g. add it to your ~/.bash_profile.

logout and login or source ~/.bash_profile and trashing will work

or

echo 'export ELECTRON_TRASH=gio' >> $HOME/.bashrc
source $HOME/.bashrc

[cutephoton]

Gio operates the same way. I used the Gio command line to manually step through this...

[mh-cbon]

running fedora 29, i have installed atom from packages, since recently I faced the same error as described here.

sudo dnf list installed atom
Paquets installés
atom.x86_64                                                1.33.0-0.1                                                 @Atom

I think this bug deserves an action in order to improve the package installation, or the runtime, to detect gio/gvfs and make this work out of the box.

This really is an ugly bug for the end user experience.

[cristianlivella]

Is there any workaround to delete files with Atom on Fedora 29?

[edlefebvre]

So as @rsese mentioned you need to set ELECTRON_TRASH=gio e.g. add it to your ~/.bash_profile.

logout and login or source ~/.bash_profile and trashing will work

This is not working on fedora 29, even with gio installed and ELECTRON_TRASH variable set to gio.

[cutephoton]

There are no workarounds.

[olegjs]

So as @rsese mentioned you need to set ELECTRON_TRASH=gio e.g. add it to your ~/.bash_profile.
logout and login or source ~/.bash_profile and trashing will work

This is not working on fedora 29, even with gio installed and ELECTRON_TRASH variable set to gio.

Works on my Fedora 29 -- had to restart terminal and restart atom from that terminal.

[rugk]

BTW for anyone on Fedora who wants an easy "fix": The flatpak version of Atom works fine… 😃

[rdazvd]

BTW for anyone on Fedora who wants an easy "fix": The flatpak version of Atom works fine…

Installing the flatpak version worked for me as well (Fedora 29). It is a solution, although installing via flatpak means giving up CLI tools.

[cutephoton]

I would direct people to actually read the bug report before commenting. Somebody please lock down this issue.

[rugk]

although installing via flatpak means giving up CLI tools.

You can expose them, so they spawn outside of the flatpak. See https://github.com/rugk/atom-flatpak-wrapper/.

Anyway, this is getting off-topic.

@cutephoton See no reason for a lock here. The issue is not really fixed or so… or Fedora has to fix it (then one needs to notify them), whatever…

[ghost]

A small trick that is not a solution but probably do it for most. Install the permanent-delete plugin and use shift+del. It is made to bypass the trash can but it's a quick work around. 〰️

[Arcesilas]

A small trick that is not a solution but probably do it for most. Install the permanent-delete plugin and use shift+del. It is made to bypass the trash can but it's a quick work around. wavy_dash

There are already better workarounds which do not permanently delete files.

[lee-dohm]

@cldtech and @Arcesilas your comments were deleted as a violation of the Atom Code of Conduct as they were insulting or derogatory.

[rafeca]

Atom is using an electron API to move items to the trash, this API used to default to gvfs-trash but this got changed in electron v3 to default to gio.

We're planning to upgrade to Electron v3 very soon (WIP PR), so this issue will get resolved quite soon.