GNOME Bugzilla – Bug 170761
Folders become inaccessible after performing deletion during ftp.
Last modified: 2009-10-24 23:48:03 UTC
1. Invoke nautilus and ftp to remote desktop using ftp://user:passwd@ipaddress 2. Browse to the destination and create a new folder 3. Transfer few files into the newly created folder. 4. Delete the newly created folder and again create a new folder. Observation and bug: Nautilus does not allow opening or renaming the newly created folder. Also all the folders in the window become inaccessible in a similar way. If we are selecting list view, renaming is possible although opening a folder is not possible.
that works fine here with nautilus 2.10. what version of nautilus are you using ?
I'm able to reproduce this behaviour with nautilus 2.10.1. Could you please try repeating the above mentioned steps. Sometimes at very first time when user ftp the bug is not seen, but repeating these steps again and again will surely land into bug. Thanks
That works fine here .. What FTP server do you use ?
I tried with nautilus/gnome-vfs built from HEAD. I tried with different versions of ftp servers on different distors and saw the problem. - 1.2.1-7 (Fedora Core 3) - 1.2.1 (SUSE Linux kernel 2.6) - 1.1.0 (SUSE Linux 2.4 kernel) - 11.10.0 (Solaris 10) If you don't see the problem first time with ftp, then restart nautilus and try the steps.
Easy way to reproduce the bug: 1. Invoke nautilus and ftp to remote desktop using ftp://user:passwd@ipaddress. 2. Create a folder and double click the folder. The location will be listed in history list, as seen from GO menu. 3. Browse back to parent location and delete the newly created folder. 4. Try creating a new folder from the same parent location. The newly created folder can not be opened or renamed. 5. Try opening/renaming other existing folders. User will find problems.
The problem is in nautilus bookmarks handling, while browsing through remote locations like ftp, smb etc. After evaluating, its found that the problem occurs due to the following code in nautilus-bookmark.c:nautilus_bookmark_connect_file(): if (!nautilus_bookmark_uri_known_not_to_exist (bookmark)) { bookmark->details->file = nautilus_file_get (bookmark->details->uri); g_assert (!nautilus_file_is_gone (bookmark->details->file)); g_signal_connect_object (bookmark->details->file, "changed", G_CALLBACK (bookmark_file_changed_callback), bookmark, 0); } For a local file, before updating the bookmark->details->file field, we check whether the file actually exists by calling nautilus_bookmark_uri_known_not_to_exist() function . If the file is deleted from trash, its bookmark will be disconnected. But for a non local file, the function always returns false. So even if file is removed permanently, the above code gets executed and file gets recreated for a non existing URI and bookmark file field will be updated. Since the file itself does not exist, nautilus will try to get its information, causing an infinite loop to occur. I am not sure how to find that a non local file is really gone and disconnect its bookmark. Tried replacing nautilus_file_get in the above code with nautilus_file_get_existing, which will make sure that file is not recreated for a non existing URI. It solved the bug. Is it right way to fix it ? If so, I can upload a patch. Kindly give your valuable advice.
Created attachment 39555 [details] [review] Attached patch fixes the bug.
Comment on attachment 39555 [details] [review] Attached patch fixes the bug. Marking as needs-work as reviewed on nautilus-list.
This was likely fixed with the fix of bug 165530. Please verify.
I could still see the problem, Thanks..
with the CVS version and the pointed changes?
The patch given for the bug#165530, partially addresses this problem too. Nautilus doesn't hang any more. But still we are not able to rename the newly created folder or already existing folders. All other file operations such as open, cut ,copy etc work fine now. To see the problem: Do steps 1-3 mentioned in comment #5. Try renaming the newly created folder or already existing ones- Nautilus doesn't allow this. Please note that renaming a folder inside the parent location where we performed the operation works. Thanks.
reopening according to comment
This bug is rather old (~4y). I could not reproduce the bug with Nautilus 2.28.1 after doing all kind of crazy manipulation and the mentioned one 5 times, so this is certainly fixed. The GVFS migration certainly helped a lot since then. Could you try to reproduce with a more modern installation? Or we directly close it as RESOLVED/FIXED or RESOLVED/OBSOLETE?
Thanks for testing. Reporters: please reopen if you can reproduce with up-to-date versions of Nautilus and GVfs.