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.
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?
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.
I think there is more wrong with that append_escaped_name loop. The first = FALSE assignment needs to be in the if (first) block
Also, adding that computer:// bookmark to my .gtk-bookmarks file reproduces the symptoms.
Nice spotting of the first = assignment. I'm fixing in svn. I'll try to add a computer bookmark here.
Adding computer:///noexist gives the same failure. Looking into it.
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.
Should be fixed in 2.24.1 in rawhide