GNOME Bugzilla – Bug 165530
hang after removing directory containing files
Last modified: 2005-05-18 11:37:23 UTC
Please describe the problem: Open burn:/// Create directory "foo" in burn:/// Open directory "foo" Create file "bar" in "foo" Close directory "foo" Remove directory "foo" using nautilus The directory is removed from burn:/// but the CPU goes to 100% and stays there while the burn:/// location is open. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Here are the method calls made on mapping_method immediately after using the Del key to remove the directory burn:///foo: do_get_file_info: burn:///foo do_get_file_info: file /foo result 25 do_get_file_info: burn:///foo do_get_file_info: file /foo result 25 do_open_directory: burn:///foo do_read_directory: 0x8f0ac28 do_open_directory: burn:///foo/bar do_read_directory: 0x8f23798 do_close_directory: 0x8f23798 do_read_directory: 0x8f0ac28 do_close_directory: 0x8f0ac28 do_get_file_info: burn:///foo do_get_file_info: file /foo result 25 do_open_directory: burn:///foo do_read_directory: 0x8f0ac28 do_open_directory: burn:///foo/bar do_read_directory: 0x8f23798 do_close_directory: 0x8f23798 do_remove_directory: burn:///foo/bar do_open_directory: burn:///foo do_read_directory: 0x8f0ac28 do_close_directory: 0x8f0ac28 do_remove_directory: burn:///foo do_read_directory: 0x8f0ac28 do_close_directory: 0x8f0ac28 do_get_file_info: burn:///foo do_get_file_info: file /foo result 1 do_get_file_info: burn:///foo do_get_file_info: file /foo result 1 [Continues to loop]
This seems to stop the looping: Index: libnautilus-private/nautilus-directory-async.c =================================================================== RCS file: /cvs/gnome/nautilus/libnautilus-private/nautilus-directory-async.c,v retrieving revision 1.212 diff -p -u -r1.212 nautilus-directory-async.c --- libnautilus-private/nautilus-directory-async.c 22 Nov 2004 15:24:35 -0000 1.212 +++ libnautilus-private/nautilus-directory-async.c 28 Jan 2005 21:47:04 -0000 @@ -2809,7 +2809,8 @@ get_info_callback (GnomeVFSAsyncHandle * nautilus_file_update_info (get_info_file, result->file_info, has_slow_mime_type); } - nautilus_file_changed (get_info_file); + if (!get_info_file->details->is_gone) + nautilus_file_changed (get_info_file); nautilus_file_unref (get_info_file); async_job_end (directory, "file info");
Not sure if this is a proper fix or just a workaround. Moving to nautilus for comment.
could you mail the patch to the nautilus-list to get it reviewed ?
any news on this bug? have you mailed the list?
Should be fixed with this: 2005-05-16 Alexander Larsson <alexl@redhat.com> * libnautilus-private/nautilus-bookmark.c: (bookmark_file_changed_callback): Don't loop when a bookmarked file is removed * src/file-manager/fm-directory-view.c: (process_new_files): Don't call get_file_info for files no longer in the directory (was caused by the ready_to_load call). This fixes #165530 and likely #170761
I could still see this problem with the recent change.
Oops, Sorry i wanted to update for the bug #170761. Please ignore the comment #7. Thanks.