The problem is not the program crashing, but I guess rather an issue with the way the behavior with shares is designed. The hang is only due to the cifs subsystem trying to access the unavailable share, and nautilus (and any other program that might want to access the share location, even the terminal, wait for the cifs subsystem to answer, which is what causes them to "hang". With my limited knowledge of the cifs subsystem I'd summarize the issue to the following points: - CIFS waits too long before giving up accessing an unavailable share. It should either give up sooner or/and there should be a settable timeout option somewhere. Additional a "brute-force" option to the umount command would be usefull, as both -l and -f seem to want to contact the host before unmounting, which makes the process terribly slow. - Nautilus and all nautilus-related applications hang if one instance tries to access an unavailable share, this because that specific instance waits for a response from the cifs subsystem.
I am not sure if this behavior is limited to cifs shares, possibly it is the same for ssh shares and other. Also, I am not sure this issue has only to do with gvfs: from what I can judge it is gvfs for the part that concerns every nautilus-related application to hang, for the rest the core utilities such as umount themselves. -- Unreachable network mounts cause annoying hangs https://bugs.launchpad.net/bugs/341463 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
