consider renaming internal ssh.exe to prevent sshfs-win picking up system tool with the same name about sshfs-win

[billziss-gh]

Interesting Sshfs-win.c sets the path to /bin, so I would not have expected any issues.

I am not sure about this, but I believe that sshfs hardcodes the ssh name, so it might not be possible to rename it (except perhaps with a patch).

I think the correct solution is to find out why sshfs may pick up the wrong ssh at times.

[billziss-gh]

https://github.com/billziss-gh/sshfs-win/blob/master/sshfs-win.c#L33

[4O4]

@mhogomchungu @billziss-gh SiriKali is using sshfs.exe directly and not through the sshfs-win.exe proxy which actually sets the env

[mhogomchungu]

Which one of the two is SiriKali supposed to be using?

[billziss-gh]

Sshfs-win.c is a simple wrapper that is used to support the Windows \\sshfs\... syntax. I think SiriKali can use sshfs.exe directly (so that it also has access to its various options), but with some care in setting up the PATH, etc.

[4O4]

Sshfs-win.c is a simple wrapper that is used to support the Windows \sshfs... syntax.

Sorry for an off-topic question, but I'm getting more and more curious about all these projects surrounding sshfs for windows. Where exactly is this magic responsible for \\sshfs syntax implemented? Here or somewhere in WinFSP or elsewhere?

[billziss-gh]

The \\sshfs ("UNC syntax") support is provided by WinFsp.

EDIT: If you want the full story read this: WinFsp Service Architecture

[4O4]

Thanks! I'm gonna dig into it. I really like your projects, amazing job on the detailed documentation 👍

[billziss-gh]

Thanks :)

[4O4]

There's another occurence of this problem, but it's now cygwin's fault instead. See: #37 (comment)

While renaming internal ssh.exe might solve the issue, I don't think it is a good idea. I think it's better to keep these executables as close to original as possible to avoid any confusion. Maybe move it to some isolated subdirectory instead?

It would also be nice to make a proper public CLI wrappers. For example: there could be a new sshfs.exe proxy whose only job would be to init the env and then redirect all command line args straight to the original sshfs.exe (which should be isolated and not in PATH so it can't be accidentally called). All WinFsp-related customizations and hardcoded options could be extracted from sshfs-win to sshfs-fsp / sshfs-winfsp and sshfs-win.exe itself should be removed. In my opinion it would provide the best user experience no matter if one prefers mounting drives directly via CLI or mapping them with Explorer. What do you think?

PS I'm volunteering to help and work on this of course

[billziss-gh]

The primary purpose of sshfs-win.c is to facilitate running sshfs through the WinFsp Launcher. Not everything that it does applies to command-line usage.

The Launcher is a Windows service and it runs in the context of the SYSTEM account (by default). So when it launches sshfs-win it does so in the SYSTEM context. But running sshfs in the SYSTEM context without the proper options is not very useful, because it gives file access to the SYSTEM account, but not to the user account that started the file system.

So sshfs-win.c determines the user account that actually started the file system and runs sshfs with the appropriate uid, gid options.

Of course, sshfs-win.c does some other things as well, like setting up the environment and default command-line parameters. For example, sshfs-win.c passes the special option -opassword_stdout, which instructs sshfs to respond OK when authentication succeeds. This is to support password-based authentication via the Explorer, etc.

Having said that I can see the usefulness of an sshfs proxy that could be used both from the WinFsp Launcher and the command line. What would the command line interface for such a utility look like in your opinion?

[4O4]

When I find some spare time I will make a few experiments based on the ideas from my previous comments and the insights you have provided. If there's anything useful born in the process then I think it's gonna be the best if I come back with an initial PR and we'll continue from there :)