From Bugzilla Helper:


While trying to investigate the tree performance issue and some random
tree flakiness I have started seeing, I found a bug exposed by my
changes to nautilus-directory-async.c which, among other things, make
deleted or missing files get marked gone on a directory load.

The problem comes up when you have a bookmark for a nonexistent file
and nautilus loads the directory that file is in - either through the
tree view or by visiting the location or through other means.

I've put further details on the mechanism of why this happens below, but I am
not sure what to do to fix it.


* REPRODUCIBLE: Always

* STEPS TO REPRODUCE:

With the tree view and desktop off (to avoid other possible sources of
confusion):

1) Create a throwaway file in your homedirectory of a type that nautilus can
view.
2) Visit the file.
3) Bookmark it.
4) Exit Nautilus.
5) Remove the file.
6) Start Nautilus.


* ACTUAL RESULTS: 

 Nautilus goes into an apparent infinite loop where the spinner keeps spinning
but the icon view never draws at step 6.

* EXPECTED RESULTS: 

  Nautilus should start normally.

----------

What happens is this:

1) On the load, NautilusDirectory notices the file is gone, so it
   removes it from the directory and marks it gone - this issues a
   "changed" signal for the file.

2) The NautilusBookmark for the file notices the "changed" signal. In
   `bookmark_file_changed_callback' it disconnects from the file and
   unrefs it, and gets a fresh nautilus file for the same location.

3) After the signal handlers are done, the natuilus-directory-async
   code does an `async_state_changed' to kick off possible fresh I/O.

4) The async code notices that the fresh NautilusFile in the directory
   does not have file info, so it kicks off a fresh get_file_info for
   the file's URI.

5) Back to step 1, over and over


I have also verified this does not happen if I #ifdef out the
disconnect from the old file and connect to a new file in
nautilus-bookmark.c:bookmark_changed_callback. I'm not checking in that change
because it would result in a failure to detect a new file for the location
reappearing.

I think this is a design collision between the bookmark code and the directory
code - NautilusDirectory does not expect anyone to try to monitor nonexistent
files or hold on to gone files for a long time, but the bookmark code wants to
do exactly that.



------- Additional Comments From sullivan@eazel.com 2000-11-30 09:03:49 ----

I've had a bookmark for a nonexistent file in my bookmarks menu for a long time
now, and I never had this problem until today. But now, sure enough, I can't
launch Nautilus due to this. So I strongly suspect that the change that caused
this was made yesterday. Maciej's big check-in seems suspicious.



------- Additional Comments From sullivan@eazel.com 2000-11-30 10:02:30 ----

I've redesigned the nautilus-bookmark code a little to eliminate this problem;
still need to have this code reviewed.



------- Additional Comments From mjs@noisehavoc.org 2000-11-30 14:34:23 ----

Yes, this problem was unmasked by my big change yesterday, which made gone files
get detected as such on a load or reload (previously if the get_file_info failed
with GNOME_VFS_ERROR_NON_EXISTENT the NautilusFile would still not get marked as
gone). However, I believe my change is correct and the bookmark code was wrong.




------- Additional Comments From sullivan@eazel.com 2000-11-30 15:42:36 ----

I agree that mjs's fix was correct, and that the old bookmark logic was
untenable. I've fixed it now.



------- Additional Comments From brett@eazel.com 2001-01-13 21:13:39 ----

Verified.  I like the way this is handled.  Bookmarks to lost files are still
present, but shown with a question-mark emblem.  Activating the bookmark
presents an informative dialog, and prompts the user about removing all
bookmarks that lead to nowhere.



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:46 -------