GNOME Bugzilla – Bug 555234
Restore from trash is not working properly
Last modified: 2009-01-28 15:56:38 UTC
Please describe the problem: After restored a file from the trash, right-clicking on the file restored, the "Restore" entry is still present. Selecting this entry, the overwrite confirmation appears. Steps to reproduce: 1. Restore a file from the Trash; 2. Right click on restored file; 3. The "Restore" entry is still present in the popup menu. Actual results: Restoring again, the overwrite confirmation appears. Expected results: The Restore entry should disappear or should appear only if in the Trash. Does this happen every time? Yes Other information: On the restored file icon is present a "lock" icon in the top-right corner.
I have the issue here too, confirming the bug. Note also that Restore action and lock icon disappear pressing F5 or restarting nautilus.
*** Bug 559487 has been marked as a duplicate of this bug. ***
This doesn't happen anymore in trunk, I guess this has been fixed by 2008-10-17 Alexander Larsson <alexl@redhat.com> * libnautilus-private/nautilus-directory-async.c: * libnautilus-private/nautilus-directory-private.h: Add nautilus_directory_has_active_request_for_file which returns true if monitoring or call_when_ready the file or all the files in the directory. * libnautilus-private/nautilus-directory.c: (nautilus_directory_add_file): When adding a file to a directory, if there is an outstanding request for the file, add it to the work queue so we make sure to do i/o on it. Otherwise we could for instance block a call_when_ready with file=NULL because we're waiting for something to happen on all files in the dir but the newly added file never has any i/o happen to it. Closing as FIXED.
*** Bug 557849 has been marked as a duplicate of this bug. ***
I just built glib, gvfs, nautilus etc trunk yesterday and I still see this issue. Can anyone else confirm anything changed for them?
*** Bug 562369 has been marked as a duplicate of this bug. ***
Reopening for last comment, I will test this again with all the libs from trunk and see if I can reproduce.
*** Bug 562497 has been marked as a duplicate of this bug. ***
*** Bug 561906 has been marked as a duplicate of this bug. ***
*** Bug 563830 has been marked as a duplicate of this bug. ***
Created attachment 126983 [details] [review] a patch for this bug More details can be found at https://bugzilla.novell.com/show_bug.cgi?id=456702
Patch is pretty clearly unacceptable; doesn't follow coding style or conventions, not C89 (defines variable in the middle of the block), synchronous I/O is forbidden in most places in Nautilus, and we already have mechanisms in place that do precisely what you're getting at in the patch (namely nautilus_file_invalidate_attributes in this case). I'm not 100% sure that this is the right place to invalidate the attributes either, but it's probably closer to the real problem than I've managed to locate. It doesn't seem that the code path from nautilus_file_operations_move() in fm-directory-view.c, through the update queue and to the nautilus directory code ever calls nautilus_file_invalidate_attributes() on the file /after/ the file has moved to the new location, which will trigger the update of the menus and the clearing of the bogus "lock" icon.
*** Bug 569038 has been marked as a duplicate of this bug. ***
Created attachment 127400 [details] [review] use nautilus_file_invalidate_attributes This patch implements what is suggested in the last comment from awalton.
Committed to trunk. 2009-01-28 Cosimo Cecchi <cosimoc@gnome.org> * libnautilus-private/nautilus-directory.c: (nautilus_directory_notify_files_moved): Invalidate file attributes after it has been moved, so that they are refreshed properly (#555234).