7

One of the way that make the laptop reach for its limits is when its clearing up the trash in a gnome based DE with nautilus based FM. With the trash has about a plethora of files (for example, a copy of the whole android open source project) clearing it up makes it very hot and stop before it can delete them.

Based on top, the process gvfsd-trash uses about 50% plus it will take a long time to do it. Clearing the directory ~/.local/share/Trashor any directory where the "trash files" go for a hope of a salvation from deletion with a rm -rf command do the task a whole lot faster than gvfsd-trash. What does gvfsd-trash do to do that compared to a simple rm -rf command?

1
  • Please support result of ps aux |fgrep gvfs – mja Feb 16 '17 at 1:26
1

I have a hate-hate relationship with gvfsd-trash. I think can work well on a single PC but with a small office network it can become a bit of a nightmare. I suspect that when it empties the trash, it does the "tidying up" as it goes along. That can get complicated when mount points are moved or permissions & ownerships are changed. It also seems to tie up the CPU for long periods trying to work things out each time the machine starts.

My technique when gvfsd-trash starts slowing down the machines is to use:

$ sudo rm -rf ~/.local/share/Trash

This gets rid of the Trash on my own machine. The daemon also creates directories called ".Trash-1000" in the roots of the network mounts. Deleting them using

$ sudo rm -rf [..path to file..]/.Trash-1000

from the server where each network share resides cures a lot of performance problems. Here "1000" is my UID, yours may be different. "gvfsd-trash" seems to be quite good at getting rid of it's baggage once the Trash directories are gone.

NOTE: "This works on a Ubuntu / Mint system where "sudo" provides root privileges. With other distros use the appropriate technique. If the "rm" command works without root privileges all the better but the problem is usually at its worst when it can't.

0

I'm not very familiar with gvfsd-trash, but I think there are a couple of things that contribute to this. The GNOME Trash folder applies to files and folders across the entire system and even on the network. So, I believe it keeps a database of where those files were originally stored so that if you go right-click on a file in the Trash folder and restore it, it knows where to restore it to. It also likely keeps some other metadata about those files - like the timestamp of deletion, perhaps original ownership, access time, and modification time information - data that would normally be "lost" when the file is moved from some location on the system to a user's trash folder. In the case of something like an Android source directory, that is a lot of files to keep that kind of metadata about, and my guess is that delete those from the Trash folder takes a while to clean up all that information.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.