After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 46714 - Nautilus ceases to respond accessing NFS volume if network down
Nautilus ceases to respond accessing NFS volume if network down
Status: RESOLVED NOTGNOME
Product: nautilus
Classification: Core
Component: general
0.x.x [obsolete]
Other Linux
: Normal normal
: old
Assigned To: Michael Fleming
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2001-02-16 20:36 UTC by eli
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description eli 2001-09-10 00:57:59 UTC
If you yank the network connection and then attempt to access an NFS volume,
Nautilus will freeze.

(4573 covers a similar problem, but is http specific. So, I'm filing a separate
bug to cover the NFS case. Perhaps they're the same bug; I have no idea.)

* REPRODUCIBLE: Always

* STEPS TO REPRODUCE:

1. Launch Nautilus on an Eazel system with NFS mounted at /h.
2. Go to "/h/{your user name}"
3. Unplug your network connection
4. Press refresh

* ACTUAL RESULTS: 

 The Eazel throbber will throb indefinitely. 

If you press "Stop", but Stop button remains depressed, and the Nautilus window
will fail to update (e.g. if you drag it offscreen and on screen.)

* EXPECTED RESULTS: 

  If I connect to a file server on a Mac (OS 9.0) and unplug the Ethernet
connection, well...err...it just times out, too, and requires me to restart or
force-quit the Finder.

Darin suggests that we do better than the Mac in this case, and that Nautilus
should recover gracefully from losing network connectivity.



------- Additional Comments From eli@eazel.com 2001-02-16 15:36:51 ----

...eventually, Nautilus will fail to respond to GNOME, and the user will be
asked if they'd like to quit the program.



------- Additional Comments From darin@bentspoon.com 2001-02-20 09:33:54 ----

We just have to figure out what specific sync. I/O we are stuck in here. Simply
running under the debugger is the next step. Since I am off-site and don't have
access to NFS I'm a bad choice to do this next step so we need to find someone
else.



------- Additional Comments From darin@bentspoon.com 2001-02-20 09:36:21 ----

Wait, the specific case of losing the home directory is much worse than the
normal case. I don't think there's a good chance of making this work if it's the
home directory that's lost. The general "losing NFS" bug is much simpler than
the "losing the home directory which is NFS".



------- Additional Comments From don@eazel.com 2001-02-20 09:44:47 ----

Arik, can you please get some debugging data for Darin here?  Thanks.




------- Additional Comments From arik@eazel.com 2001-02-20 12:07:48 ----

sure.



------- Additional Comments From mikef@praxis.etla.net 2001-02-21 18:15:51 ----

This is a really really rough bug to fix.

It should be noted that shells almost always hang when your nfs home directory
is offline, since programs can't dot files in your home directory.  Also,
stating on the current working directory hangs.

As far as what happens when nfs fails on a a directory other than your home
directory, results can be pretty rough too.  Many applications (pine, for
example) and even file browsers (the old NeXT workspace manager) get murdered by
this case.

We can't solve this problem in general.  There's nothing that we can do when the
affected directories contain the user's home directory, shared libraries or
resources used by nautilus or its libraries (eg, image files, oaf files).

In the specific case of an NFS mount that contains data not required for normal
system operation, it would seem reasonable to be able to stop and hit "back".  I
wouldn't be surprised if this already worked based on Pavel's recent 6390 fix. 
Has anyone tried just this specific case?



------- Additional Comments From don@eazel.com 2001-02-21 21:11:15 ----

Yes, some please try the specific case real soon now.




------- Additional Comments From mikef@praxis.etla.net 2001-02-22 16:25:31 ----

Don--Don't worry, I have this one under control.



------- Additional Comments From mikef@praxis.etla.net 2001-02-22 17:53:49 ----

The bad news is disconnecting from an NFS server, even if it isn't providing
necessary system resources, still hangs nautilus because there are cases where
synchonous filesystem calls are made.  One example is
nautilus_uri_is_trash_folder (An experiment indicates that Nautilus can hang
here)

Further investigation brings worse news...  It appears that disconnecting the
nfs server can hang nautilus so hard that I can't even break into it in a
debugger.  And it appears that it hangs the entire process, even if only a
single thread is involved in io to the nfs server.  It seems like some stuff is
baked deeper in Linux.

Anyway, I really don't think we can fix this for 1.0, folks.  In fact, I think
that we won't be able to ever fix it completely.



------- Additional Comments From mikef@praxis.etla.net 2001-02-22 17:54:23 ----

Marked P6 with a NULL milestone so it can be revisited by the triage crew.



------- Additional Comments From don@eazel.com 2001-02-23 03:32:07 ----

Ugh.  OK, at Mike's recommendation, I'm moving this warily to 1.2 as a P2 bug.




------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:57 -------
Bug blocks bug(s) 46711.
Comment 1 John Fleck 2002-01-05 04:14:24 UTC
Changing to "old" target milestone for all bugs laying around with no milestone set.
Comment 2 Aschwin van der Woude 2002-11-11 22:52:13 UTC
This happens with any program accessing an unreachable nfs mount.