GNOME Bugzilla – Bug 763218
Trash enumeration is not synchronized with the system
Last modified: 2016-04-26 12:11:33 UTC
If the trash contents are enumerated right after a trash operation, the trashed file appears not to be there. I suspect this is due to the trash backend using an internal cache for enumeration, which does not get updated immediately. This issue affects nautilus because restoring files from the trash is done by querying the contents of the trash. Since they are not updated quick enough, the trashed files will appear not to be there.
The "cache" for filesystems with reliable notifications is updated on signals from g_file_monitor only if trash dir is being monitored. I suppose that the file notifications might be delayed and thus the file might not be listed immediately after g_file_trash. However, I am not able to reproduce such situation (even not when trashing thousands of files), so I can't test it :-( Are you able to reproduce it using some "simple" code?
Created attachment 323516 [details] [review] trash: Check modification time to be sure rescan is not needed Rescan trash directory also on filesystems with reliable notifications, because notifications might be delayed and thus trash_dir_rescan is still needed in order to be sure that trashed file is listed from the backend immediately after g_file_trash call.
Razvan, could you try the attached patch whether it fixes mentioned problems for you?
Comment on attachment 323516 [details] [review] trash: Check modification time to be sure rescan is not needed Sorry, I've messed up the description of the patch (I used description for another patch, which just forces rereading, but I do not intend to publish it)... Check modification time on trash directory even if it is on a filesystem with reliable notifications, because notifications might be delayed and thus trash_dir_rescan is still needed in order to be sure that trashed file is listed from the backend immediately after g_file_trash call.
Are you certain that this isn't really bug 749314?
Ryan, thank for notice, I didn't know about it, but it is probably something else...
Comment on attachment 323516 [details] [review] trash: Check modification time to be sure rescan is not needed I realized that the patch is a bit wrong and it forces rereading after each change, because mtime isn't actualized by the signals (I thought that trash_dir_enumerate is invoked when signal comes, but it isn't... ). So the patch ensures that enumerate contains all the files, but it is not right way to do this...
However, it seems that file monitor signals are fast enough according to my testing. It seems that there is another problem. The bug appears only in Nautilus when undoing trash operation for thousands of files (and the attached patch doesn't have any influence on it)... Debug output shows that Nautilus floods trash backend by thousands of enumeration jobs. Trash backend is not able to handle all those requests... and you can see high cpu usage for several minutes... as a consequence the jobs probably timeout and you can see following warnings: ** (process:30930): WARNING **: send_infos_cb: No such interface 'org.gtk.vfs.Enumerator' on object at path /org/gtk/vfs/client/enumerator/732 (g-dbus-error-quark, 19) Nautilus seems to wait for a result from the latest enumeration job, but it won't get the result probably because the operation timeouts before... so it won't complete the undo operation even after the several minutes. We have to figure out why thousands of enumeration requests are queued and deal with it somehow...
*** Bug 763394 has been marked as a duplicate of this bug. ***
(In reply to Allison Ryan Lortie (desrt) from comment #5) > Are you certain that this isn't really bug 749314? Actually, the file monitor changes mentioned in this bug might be a root of the problem... Because nautilus/xfdesktop got notifications earlier and thus spawns enumerations earlier...
Created attachment 323843 [details] [review] trash-monitor: change trash monitoring process In Nautilus, the trash is monitored for state changes - going from empty to non-empty and the other way round. Monitoring is done by handling change signals from a regular file monitor. On each signal, an enumeration of the trash contents is started in order to see if it is empty or not. This causes issues when many files are trashed, because the gvfs trash backend is flooded with enumeration requests, resulting in CPU usage spikes. In order to fix this, the "item-count" attribute of the trash should be queried instead. Replace asynchronous enumeration with asynchronous information query and update the trash state based on the "item-count" attribute.
Created attachment 323932 [details] [review] trash-monitor: change trash monitoring process In Nautilus, the trash is monitored for state changes - going from empty to non-empty and the other way round. Monitoring is done by handling change signals from a regular file monitor. On each signal, an enumeration of the trash contents is started in order to see if it is empty or not. This causes issues when many files are trashed, because the gvfs trash backend is flooded with enumeration requests, resulting in CPU usage spikes. In order to fix this, the "item-count" attribute of the trash should be queried instead. Replace asynchronous enumeration with asynchronous information query and update the trash state based on the "item-count" attribute.
I realized that some modifications are needed for the trash backend in order to be sure that valid item-count is reported. See Bug 711459.
Review of attachment 323932 [details] [review]: LGTM thanks!!
Attachment 323932 [details] pushed as a99b4cf - trash-monitor: change trash monitoring process
*** Bug 749372 has been marked as a duplicate of this bug. ***
Will this fix be included in 3.20.x too?
GVfs part is aleady in gnome-3-20, not sure about Nautilus and GTK+ part...
According to git, they nautilus and gtk+ part are not.