Bug 465479

Summary: nautilus "Computer" window doesn't work
Product: [Fedora] Fedora Reporter: Ray Strode [halfline] <rstrode>
Component: nautilusAssignee: Tomáš Bžatek <tbzatek>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: alexl, bnocera, mclasen, tbzatek, tsmetana
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-21 04:06:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 457945    

Description Ray Strode [halfline] 2008-10-03 14:49:35 UTC
If I doubleclick on "Computer" on my desktop it doesn't show up.  Instead it just sits there with "Loading..." in the titlebar and a gray windows, with the status bar desensitized.

Comment 1 Tomáš Bžatek 2008-10-07 13:45:14 UTC
Can you please try gvfs-1.0.1-5.fc10? You might have experienced similar behaviour as with network:// - a warning message aborting the backend. I had no luck reproducing this original issue though. What gvfs mounts do you have active?

Comment 2 Ray Strode [halfline] 2008-10-07 14:58:20 UTC
It doesn't work with gvfs-1.0.1-5.fc10 either.  The problem seems to be this entry in my ~/.gtk-bookmarks:

computer:///sftp%20on%20halflap.usersys.redhat.com.mount

Also, I ran gvfsd-computer through valgrind and noticed this:

common/gdbusutils.c (append_escaped_name):
...
   gboolean first;
   static const gchar hex[16] = "0123456789ABCDEF";
 
+  first = TRUE;
   while ((c = *unescaped++) != 0)
     {
       if (first)
....

Notice if you ignore the "+ first = TRUE;" line I added, that the if (first) check is reading first before it's initialized.

The problem is probably unrelated I guess.

Comment 3 Matthias Clasen 2008-10-07 17:05:53 UTC
I think there is more wrong with that append_escaped_name loop.
The first = FALSE assignment needs to be in the if (first) block

Comment 4 Matthias Clasen 2008-10-07 17:10:02 UTC
Also, adding that computer:// bookmark to my .gtk-bookmarks file reproduces the symptoms.

Comment 5 Alexander Larsson 2008-10-17 09:23:17 UTC
Nice spotting of the first = assignment. I'm fixing in svn.
I'll try to add a computer bookmark here.

Comment 6 Alexander Larsson 2008-10-17 10:01:23 UTC
Adding computer:///noexist gives the same failure. Looking into it.

Comment 7 Alexander Larsson 2008-10-17 17:25:25 UTC
The problem is that the bookmark caused the NautilusFile for the bookmark location to immediately be re-created when the file is noticed as deleted. 

Reading computer:/// lead to it being noticed as deleted, and the new NautilusFile created caused problems due to another bug where we don't correctly handle files being added to a directory while we're doing call_when_ready() waiting for all files in the directory. The problem is that we only queue i/o for the files that exist when call_when_ready() is called, but we require *all* files to be done before calling the callback, and the newly added file won't get queued for i/o.

The fix for the bookmarks issue is to not immediately re-create the file when deleted. I've commited this to head and gnome-2-24, and it will be in the next version (on monday). 

I've also got a fix for the race condition, but that is more risky (for instance, it loops if the bookmarks case isn't fixed), so it goes on trunk only.

Comment 8 Matthias Clasen 2008-10-21 04:06:20 UTC
Should be fixed in 2.24.1 in rawhide