nautilus ssh connection after suspend to ram - browsing location lost

[donquixote]

10.04 LTS - the Lucid Lynx

Following steps:
1. Places > Bookmarks > "ssh on server xyz"
(that's a bookmark I made in a remote folder)
2. I type the password to open the nautilus window with the remote folder.
3. Ctrl-T to open two other nautilus tabs in different remote folders on the same ssh connection. Navigate around in all three tabs, but stay on the remote server.
4. Open one of the remote files in gedit.
5. Suspend to RAM.
6. Wake up from Suspend.

Now we are in a strange situation:
- The gedit remote file looks like it is still open, but doing anything in there makes the gedit tab unresponsive.
- All three nautilus tabs look like they are still open, but they are unresponsive.

The only way to fix it:
7. Unmount the ssh connection (in the nautilus side pane)
(btw, left-clicking it makes the side pane scroll state jump down)

Now all but one of the remote nautilus tabs is being closed, and instead we get one nautilus tab in a local location.
The file in gedit is still open.

Now we can either
8.a) Save the file in gedit -> asks me for the ssh password, and the ssh connection is back. (but nautilus location is still lost) Or
8.b) Hit "Back" in nautilus -> asks me for the ssh password, the ssh connection is back, and the nautilus location is restored - for one of the tabs. The other tabs are still closed, the location lost.
8.c) Use again the bookmark to get to the remote location.

Now the problem is, the other two tabs are lost, and I need to navigate again to get to these locations.
So,
9. Ctrl-T to open two other Nautilus tabs. Navigate around until we are back at the locations where we have been.

To summarize, the problems are:
- Having to click around more than necessary to reconnect the ssh connection.
- Having to navigate again to get back to the folders, instead of them being remembered.

Thanks.

[kurt belgrave (trinikrono)]

Assigning to nautilus for now
Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage .

[donquixote (lemon-head-bw)]

A little workaround:

7.d) For each of the remote nautilus tabs, click "Home". Then unmount the ssh connections (in the side pane).
This prevents the tabs from being closed.

8.d) For each of the previously remote nautilus tabs, click the "Back" button.
Yeah!

Anyway, this is not a satisfactory solution.

Btw, often when I unmount an ssh connection with Nautilus, it will directly ask for the password to reconnect. Strange, that is.

[donquixote (lemon-head-bw)]

Wow.. something has changed in Nautilus!
Maybe I am on a new version? It says "2.30.1".

Now the remote ssh tabs no longer close after suspend-to-ram.
Instead,
- each of the remote tabs goes to local "Home" automatically after a suspend-to-ram.
- all ssh connections are cut off.
- the back button gets me back to the original remote location, for each tab separately.

This is a LOT better than the old behavior.
Maybe there could be better solutions, but it would require some design thinking. I can live with this solution quite well.

[kurt belgrave (trinikrono)]

Can i close this bug report then donquixote?

[donquixote (lemon-head-bw)]

I think this behavior is not as it should be.
At the time I wrote the previous message, it did work with suspend-to-ram.
Now I checked with hibernate, and again I need to manually cut ssh connection and then do something to reconnect. And before I cut the connection, things freeze.

So, the problems I have:
- the freeze on some things (Nautilus, gedit) before I cut the (broken) connection.
- the steps needed to get back to the connection and nautilus browsing state that i had before hibernation.

I suggest some of the people at ubuntu should test this, and then decide what is the intended / desirable behavior in this kind of situation. Atm it seems that there is no intentional spec about this, just anything can happen.

And please, be careful with modal dialogs, that interrupt the flow at the wrong time. The user should not care about the broken connection, until she wants to interact with the nautilus or gedit tab that depends on the connection.

[donquixote (lemon-head-bw)]

Just saying, this thing is not fixed.

Atm, what I see mostly happen:
I wake up from suspend-to-ram with 4 nautilus tabs open to an ssh location.
These are unresponsive, until I unmount the dead ssh connection. I try browsing them to a local folder, but they do not respond.
When I do this, the tabs just close.

This means, I cannot easily interrupt my work on ssh with suspend or hibernate.

There are several solutions imaginable for this.
- On the dead ssh connection, in addition to "unmount", there could be a "reconnect" or "restore connection" option.
- Unresponsive nautilus tabs, that depend on a dead ssh connection, could have a reconnect/unmount button.
- Unmounting the ssh connection would still close all those tabs.

I think, the same would make sense for external storage devices. Think of external HD, that gets disconnected from power supply during suspend / hibernate.
When they are removed / unmounted in a controlled fashion, then the nautilus tabs can close.
When they are removed / switched off during suspend or hibernate, and then just missing, the nautilus tabs should remain in a "pending" state, with a note asking to reconnect the device.

[donquixote (lemon-head-bw)]

And why is this "incomplete"?
This has followed me from version to version, and I suppose it would be easy for anyone to reproduce.

[Launchpad Janitor (janitor)]

[Expired for nautilus (Ubuntu) because there has been no activity for 60 days.]