On Wed, Jan 27, 2010 at 11:25:39AM -0800, Whoop Whouzer wrote: > I am not stating this is an NFS problem at all. I am not asking > anybody to fix anything. I asked if this issue was by design. I was > told it wasn't (as nfs is stateless). So, therefore I considered it > as a bug (which I don't believe to reside in either nfs or nautilus). > I am just trying to figure out where the problem lies. > > I am not talking about implementing "disconnected NFS" mode, > synchronisation or anything like that. There is not something > missing, there is something not working properly, somewhere, and I'm > trying to find out where.. My impression is that this is "by design" in that NFS mounts, when mounted in "hard" mode (which is the case by default) will "block" until the remote server responds. For the most part this is a good thing. Applications expect their filesystem calls to behave a certain way regardless of what type of filesystem is underneath. In this case, it seems like Nautilus tries to open the mount point and it just hangs... forever. This would be expected with an NFS mount in my view. One way I could think of getting around it would be to ensure that the NFS mount is mounted with "intr", and then get Nautilus to monitor how long it takes to read a mount point and "terminate" after a timeout is reached, perhaps flagging that mount so future accesses are quicker. Anyways, that goes beyond the scope of NFS... and good luck convincing the GNOME developers to make a change like that. :) Also, even if you mount an NFS share with "intr", you can't always guarantee that you'll be able to kill a process trying to access said mount..... at least in my experience. Ray -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
