GNOME Bugzilla – Bug 769759
Unable to delete large folders in Trash
Last modified: 2018-09-21 18:00:45 UTC
I have found that since the indicator of file operations was replaced with the notification coming from the right of the top bar rather than a popup window, that I am unable to delete large folders from Trash. Placing them in Trash sometimes means that other items (even really small ones) can't be deleted until the large folders have been moved from Trash to another location, though on other occasions all, or at least half, of the other files will be seemingly successfully deleted, though not the large folder(s). For instance I have a folder with many sub-folders, which each have many sub-sub-folders etc and lots of files... The folder's file size is about 1.7GB. I tried creating a tar of the file which was 1.8GB, I moved that into Trash and it was deleted within about a second with no trouble at all so it seems only to be folders. I looked at the properties for a large folder I placed in Trash by itself, and even though I had clicked the Empty Trash button many times now, it was staying at the same size. I find that the indicator which is meant to be indicating how it's doing to me is always just stuck at "Preparing", even when it actually deletes stuff it only ever really shows that so is not very useful. I am running Ubuntu GNOME 16.04 with GNOME 3.20, but I believe this was also present in 3.18, though not to such a bad degree (pressing the Empty Trash button many times in some cases eventually worked on 3.18, but on 3.20 I can't seem to do anything to delete the folder without first splitting it up). One thing to note though is that if I am to use the right-click option to permanently delete files and folders (which can be enabled in the Preferences) then it deletes them just fine apart from showing a huge and negative amount of files per seconds, but that is for another bug report. I have only tested this in Nautilus, I have not yet tested if it works better in a different file manager, I will comment when I have tested it with a different file manager. I initially filed a report on the matter here: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1612343 But thought I should also do so upstream.
can you try gvfs-trash in the terminal and see if it works fine?
No, that doesn't work either. I tried doing "gvfs-trash --empty" if that is what you meant?
any warnings in the journal or in the terminal? I heard some issues with gvfs and ubuntu 16.10
No, the only output I get in the journal from gvfs-trash is when I have to manually tell it to terminate and then I get this output in the journal: Oct 24 14:27:44 <Computer-Name> gvfsd-trash[1949]: send_done_cb: The connection is closed (g-io-error-quark, 18) Oct 24 14:27:44 <Computer-Name> gvfsd-trash[1949]: send_done_cb: The connection is closed (g-io-error-quark, 18) Oct 24 14:27:44 <Computer-Name> gvfsd-trash[1949]: send_infos_cb: The connection is closed (g-io-error-quark, 18) Oct 24 14:27:44 <Computer-Name> gvfsd-trash[1949]: send_done_cb: The connection is closed (g-io-error-quark, 18) Oct 24 14:27:44 <Computer-Name> gvfsd-trash[1949]: send_infos_cb: The connection is closed (g-io-error-quark, 18) Oct 24 14:27:44 <Computer-Name> gvfsd-trash[1949]: send_infos_cb: The connection is closed (g-io-error-quark, 18) Oct 24 14:27:44 <Computer-Name> gvfsd-trash[1949]: send_infos_cb: The connection is closed (g-io-error-quark, 18) Oct 24 14:27:44 <Computer-Name> gvfsd-trash[1949]: send_done_cb: The connection is closed (g-io-error-quark, 18) Oct 24 14:27:44 <Computer-Name> gvfsd-trash[1949]: send_done_cb: The connection is closed (g-io-error-quark, 18) Oct 24 14:27:44 <Computer-Name> gvfsd-trash[1949]: send_done_cb: The connection is closed (g-io-error-quark, 18) But that's just me quitting it so it is probably not much help for this issue. Also it should be noted that this issue first appeared for me on Ubuntu GNOME 16.04 with GNOME 3.20, so it's not just a 16.10 issue. In fact it just about with GNOME 3.18, it's GNOME 3.20 and 3.22 that it doesn't work so well on.
Ok thanks for the info, I don't know more on how to debug gvfs, so moving to gvfs.
Ok, I have gvfs version 1.28.2.
Hmm, "gvfs-trash --empty" just tries to recursively delete all files using GIO API, I am not really sure this is GVfs bug: https://git.gnome.org/browse/gvfs/tree/programs/gvfs-trash.c?h=gnome-3-22#n31 It looks like that there is endless recursion somewhere... I see 3 possible ways of debugging: 1/ Run gvfs-trash --empty in gdb and set breakpoint in the delete_trash_file function and check the recursion... 2/ Modify gvfs-trash binary to print filenames in order to check the recursion... 3/ I will try it myself... can you provide me the tar file? or give me at least some hints in order to generate such file hierarchy, which causes the issue for you?
I literally just ran this: mkdir test && cd test And then "apt-get source chromium-browser" (or another large package, or group of packages) until the file size of the directory was around 1.7GB. Though the first time I had this issue it was with a directory with many sub-directories containing ISO files, so it's not only package source code structured directories that this affects. Just "apt-get source" is easier to use to make a big directory because it does all of it for you, you just have to run it with some big things a few times.
Hmm, I don't see such problems with the following extracted archive: https://launchpad.net/ubuntu/+archive/primary/+files/chromium-browser_53.0.2785.143.orig.tar.xz (I suppose this is equal to "apt-get source chromium-browser") "gvfs-trash --empty" takes about 1,5 min. However, I've realized that it might be duplicate of the following bugs: Bug 763218, Bug 763600, Bug 711459...? Does it work if you just kill nautilus and then run "gvfs-trash --empty"? Can you test this against GNOME 3.22?
You have to download and unpack the archive several times until the size of the directory you are wanting to delete is about 1.7-1.9 GB (or around there at least). So I don't know if that's what you did, but just doing it once doesn't create a directory large enough to reproduce the problem. I have tested this GNOME 3.22 though and it seems to work immediately if I kill both the nautilus and the nautilus-desktop process and then run "gvfs-trash --empty".
(In reply to cooks.go.hungry from comment #10) > You have to download and unpack the archive several times until the size of > the directory you are wanting to delete is about 1.7-1.9 GB (or around there > at least). So I don't know if that's what you did, but just doing it once > doesn't create a directory large enough to reproduce the problem. The size is over 2 GB after unpacking... > I have tested this GNOME 3.22 though and it seems to work immediately if I > kill both the nautilus and the nautilus-desktop process and then run > "gvfs-trash --empty". What is a result with Nautilus in GNOME 3.22? I made test with folder bigger than 10GB: - it takes about 6 minutes using nautilus (although the progress bar still showing preparing) - it takes about 5 minutes using "gvfs-trash --empty" (with nautilus killed) (It might somehow correspond with Bug 757747...)
(In reply to Ondrej Holy from comment #11) > The size is over 2 GB after unpacking... Well, I used apt-get source, so perhaps they are actually getting different things? > What is a result with Nautilus in GNOME 3.22? On GNOME 3.22 if Nautilus is running then the command does not work, however if Nautilus is not running it works immediately. Which is also a bit strange, because I had almost 2GB worth of data and executing that command made it literally disappear the moment I executed it. Although sometimes it takes about 5 minutes. It seems to vary, normally it would take about 5 minutes, though on the occasion when I first tested it out with Nautilus running it just happened instantly. And I checked the Trash in Nautilus after that and it was just gone. Just like that, it seemed a bit too quick for me. But that does sometimes happen with other things as well like moving folders etc. > (It might somehow correspond with Bug 757747...) Maybe...
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/285.