Unable to abort connection.

[TheManticore]

So, I screwed something up and want to remap a connection.
Unfortunately, I set SSHFS-Win Manager up to autostart.
So, the manager hangs on startup, and I can't edit/delete the b0rked connection.
Additionally, I don't see a manner in which to bypass or abort the connection (I removed the Manager from autostart, however it immediately attempts to connect once I start the manager).

Halp.

Let me know if I need to provide you any diagnostic info. I think all I really need is to know where the manager stores its connections, and just blow away those settings.

kthnxby!

[TheManticore]

Welp, I found a workaround after reading some of the closed issues. I just deleted the b0rked profile in the JSON at %AppData%\sshfs-win-manager\vuex.json.

[evsar3]

You could just edit the status of the broken connection to disconnected in the same file. I will work in a automatic check if the PID of sshfs.exe still alive on the application startup.

[evsar3]

For those who have this issue this is the fix:

• Quit SSHFS-Win-Manager;
• Edit file %AppData%\sshfs-win-manager\vuex.json;
• Find the broken connection and edit it's status field to disconnected;
• Save file and reopen SSHFS-Win-Manager.

A bug fix for this will be present in the next release.

[seahindeniz]

For those who have this issue this is the fix:

• Quit SSHFS-Win-Manager;
• Edit file %AppData%\sshfs-win-manager\vuex.json;
• Find the broken connection and edit it's status field to disconnected;
• Save file and reopen SSHFS-Win-Manager.

A bug fix for this will be present in the next release.

Hi @evsar3

I have a proposal.
Can you implement a solution to avoid having this issue in the first place?
If possible, something like; when the user runs the app, the app should check the status of connections that are being mounted/connected rather than reading a static value stored in the vuex.json file.

WDYT?

[evsar3]

Hi @seahindeniz

Whats is happenning is that sometimes the program losts the track of the PID of sshfs.exe and can't determine the real state of the process.

Unfortunely in the current version I made a project mistake and didn't store the PID of the process in vuex state, only its status; thats impossibilite the connection status checking on manager startups; fixing this will require a lot of refactor, some that I have already made.
The most quicly way is to set a timeout to the manager to resolve the PID of the process; if it can't resolve the PID in the time, then it must return an error and resets the connection status to disconnected; however, if the connection is successfully, you will be unable to reconnect because the mounting point will be already in use by the process that the manager lost track. To get this working, the manager must also kill all the sshfs.exe processes witch includes the other successfull connections active in the manager and this can result in some very anoing side-effects.

I'm open for suggestions on fixing this.

[Skydev0h]

Maybe check both PID and that mount point is not in use?
If tracked process is missing and mount point is unused, it is almost certain that the connection is not established.
Moreover, if mount point is not used it is certainly possible to use it for a connection.

[evsar3]

@Skydev0h That's actually a good idea, however, what can we do when the mount point is in use but we don't have the PID of the sshfs.exe process to terminate the connection when necessary?

[evsar3]

@Skydev0h I just had an idea: When the connection times out, I can get the list of all sshfs.exe processes on the system and then check which one doesn't belongs to any of the active connections!
The only problem with that is if sshfs is being used by any other thing except other than the manager. I believe with this solution we can avoid 90% of the cases that this happens.

[evsar3]

Bug fixed in abecc43

Should be released in beta at weekend.

[evsar3]

This fix is included in v1.1.0-beta.1 release

[audouts]

I ran into this issue with 1.0.2-beta.2

I had two sites that were trying to connect and stuck spinning forever. I restarted the related services and restarted SSHFS-Win Manager but nothing helped. Eventually, I found out about editing that json file but it would be better to have a solution in the UI.

It might be helpful to have a "Reset all connection" option, somewhere that would disconnect everything.

Alternatively, we need a "force disconnect" for a specific connection.