<p>It used to be quite simple: software equivalents existed for Windows for everything we needed. Since Spring 2018, we unfortunately have to use ssh keys. This has simply added an extra step for most things, but has made one thing (rsync) really quite hard to get working.
<p>What makes this all much more tiresome is that Microsoft are introducing some cool new ways of interacting with Linux systems but these are new and need some effort to get configured correctly. See the end of this page for more details.
- well not "hard" exactly, but complicated with lot of steps that are easy to get wrong and with poor feedback as to whether you have done each step correctly.
<p>Most Windows software that we recommend "just works" if you have set up PuTTy and have done the <ahref="keyexchange.html">key-pair setup</a> and are running a local ssh agent (pagent) automatically at boot up on your laptop.
<p>Some software, such as the commercial (but free) GitKraken, requires that you click a checkbox to say that you are "using local SSH agent" rather than specifying ssh private keys explicitly (File->Preferences->Authentication in GitKraken).
<p>Linux allows characters in filenames which Windows doesn't. There are also apparently normal filenames which Windows rejects (such as "<ahref="https://answers.microsoft.com/en-us/windows/forum/windows_7-files/why-cant-i-create-a-folder-with-name/23c86662-4988-4c7d-9c2d-3e33d4413de3">CON</a>") for historical reasons. Linux filenames are case-senstitive and Windows filenames aren't: beware.
<p>Linux people like to use <em>links</em>. This is where there is really only one file, but it is referred to by different names. This is particularly useful when a file is moved, but you want people who have got the old location to still be able to find it. This happens quite a lot when updating handbooks.
<p>
The links you are most likely to come across are that what looks like
<spanstyle="font-family:monospace; size=x-small; background-color: lightgray">/home/expo/expoweb</span> is really just a link to the folder <spanstyle="font-family:monospace; size=x-small; background-color: lightgray">/home/expo/repositories/hg/expoweb</span>, <br/>
is a link to the file <spanstyle="font-family:monospace; size=x-small; background-color: lightgray">/home/expo/expofiles/gpslogs/essentials/essentials2019.gpx</span>
<p>But that example is in the <spanstyle="font-family:monospace; size=x-small; background-color: lightgray">:expoweb:</span> repository, so you won't be using sFTP to download it. Instead you will be using the version control software which handles it without problems. But we use it as an example of what to look out for when using sFTP.
There are two types of linux links: hard links and symbolic links. Symbolic links are much the same thing as Window's "Shortcuts" but there is no equivalent on Windows to Linux hard links. Fortunately we don't <em>seem</em> to have any hard links anywhere.
<p>What really makes things unpleasant is that sFTP software won't tell you when it comes across a link and will just do something stupid. Our recommended sFTP software - Filezilla - is guilty of this,as it pftp (PuTTy) working in eith sFTP or scp mode.. So what happens is that when you download a load of files onto your laptop using Filezilla it will simply turn every link it finds into a complete copy of the file. Then when you upload those files to the server, the copied file overwrites the link. So the server now has two files with the same content - which is a maintenance nightmare. This is painfully stupid because if it is a symbolic link there is no reason why Filezilla couldn't just create a Windows Shortcut which would do exactly the same thing. But it doesn't.
<p>So the ordinary user won't notice any problems, but the nerds behind the scenes start to cuss and shout and generally carry-on in an expletive-heavy manner.
<p>What is even more irritating is that Filezilla displays an link (<spanstyle="font-family:monospace; size=x-small; background-color: lightgray">essentials.gpx</span> in the image) with a little arrow - it knows perfectly well that it is a symbolic link (although it does display it with a folder icon) - but it downloads it as a file copy.
<h4>Symbolic links: the solution for Windows</h4>
<ul>
<li>When using the version control systems TortoiseHg or Git-for-Windows the download of a link works fine. But be careful not to edit the link file downloaded (it is just a text file holding the path of the file holding the actual contents) because then the version control client would upload it to the server and overwrite the link on the server with something that isn't a link. It also won't work as a Windows shortcut, but at least the default behaviour isn't actively dangerous.
<li>When using sFTP, manually check whether any files you are copying from the server are links - look at the symbol in Filezilla.
<li>Be careful not to copy any links using sFTP and instead recreate them manually on the Windows filesystem using right-click "Create shortcut".
<li>You will have to find out what to make the shortcut link to by logging in to the server (using a PuTTy ssh logon) and doing <spanstyle="font-family:monospace; size=x-small; background-color: lightgray">"ls -l"</span> in the folder where the link is.
<li>But later, when re-uploading edited files from Windows to the server, Filezilla will see the Windows shortcut as a ".lnk" file which it will upload, but which will mean nothing to the linux server receiving it. So you would have to manually recreate the symbolic link by logging into the server using ssh and using the "ln -s" command. Yuk.
<li>Even if you use scp instead of sFTP, it does the same stupid thing when copying from a linux filesystem to a Windows filesystem. The PuTTy package includes <spanstyle="font-family:monospace; size=x-small; background-color: lightgray">pscp.exe</span> but even if you force it to use the scp protocol like this:
it downloads a <em>copy</em> of the contents of essentials.gpx and not a link.
<li>A possible fix in the future might be to keep all your expo files in a separate partition of your hard disc which is formatted with a linux filesystem (such as ext4) and run the <ahref="https://www.ext2fsd.com/">ext2ntfs</a> driver to mount this fielsystem read-write from Windows. Probably not a good idea as the driver is a bit flaky in read-write mode and you could lose everything.
<p>The core problem is integrating the PuTTy key management software (pagent.exe) with a terminal window. We need a terminal window to run rsync as none of the packaged software (Filezilla, PuTTy) includes an rsync client.
<p>The solution we have now is to use WSL1 and to create another key, distinct from the PuTTy one, and to upload that key to the expo server. Because this is treating WSL as if it were a different machine requiring its own key quite separate from the Windows key, we expect this to continue to work when WSL2 becomes the default behaviour on Windows10.
The generated key is in the current directory and you need to move them to ~/.ssh/ as is standard on Linux (which is not at all the same place that PuTTy uses to keep keys on Windows).
<p>Now you have to complete the <ahref="keyexchange.html">key-pair setup</a> with the new key "id_ras_wsl.pub". But you don't need anyone else's help this time as you can use PuTTy to ssh into the server and copy your key to the right place yourself.
<li>bash window - installed by default when you install <Ahref="https://gitforwindows.org/">gitforwindows</a>. Unfortunately while this <ahref="https://en.wikipedia.org/wiki/MinGW">MINGW32</a> setup includes a comamnd-line git executable it doesn't include rsync.
<li>cygwin - a cmd terminal where you have downloaded and installed <ahref="https://www.cygwin.com/">Cygwin</a>. Yes, if you have selected the rsync package you will be able to run the rysnc executable, but it won't have access to the cyptographic key so it can't connect to the expo server. Please feel free to work out how to make this work. A more recent, graphical variant is <ahref="https://hackaday.com/2017/03/29/swan-better-linux-on-windows/">Swan</a>.
<li><imgsrc="wsl.jpg"align="right"hspace="10"><ahref="https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux">Windows Subsystem for Linux</a> aka WSL1 available on all Windows10 machines since the November 2019 update. (The first versions of WSL1 didn't do the ssh key-pair setup easily: <ahref="https://blog.anaisbetts.org/using-github-credentials-in-wsl2/">"fairly annoying because of how out-to-lunch SSH Agent is"</a> but it works now.)
<li>WSL1 <ahref="https://code.visualstudio.com/remote-tutorials/wsl/enable-wsl">Install it like this</a>. This does all we want. This works using a key generated by its own version of ssh-keygen if you follow the instructions above about putting it in the right place.
<li>WSL1: <ahref="https://hackaday.com/2019/12/23/linux-fu-wsl-tricks-blur-the-windows-linux-line/"> Converting Windows paths to Linux paths and vice-versa</a>.
<li>WSL1 will shortly be made obsolete by <ahref="https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux#WSL_2">WSL2</a> - the new wonderful system which will solve all our problems, make the tea and carry our gear up to topcamp. Allegedly.
<li>The <ahref="https://docs.microsoft.com/en-us/windows/wsl/install-win10">2019 WSL2 release</a> includes a selection of complete Linux kernels. If you want to use this, then please do - and then write the handbook documentation too. But beware that it has <ahref="https://docs.microsoft.com/en-us/windows/wsl/wsl2-index">two different modes</a> which behave differently.
<li><ahref="https://www.theregister.co.uk/2019/12/18/multipass/">Canonical Multipass</a> - a completely different alternative to WSL: more isolation, more understandable behaviour (?)
<li>A full <ahref="https://www.brianlinkletter.com/installing-debian-linux-in-a-virtualbox-virtual-machine/">virtual Linux machine</a> running using a hypervisor such as <ahref="https://www.virtualbox.org/">VirtualBox</a> which has its own virtual Linux filesystem. This setup has the advantage that you don't have to partitition your hard drive but the disadvantage that you can't get at any of the files from Windows itself except via a network protocol \\wsl$. Which may be no hardship.
<p>WSL1 unfortunately introduces a wonderful new problem of file permissions. Every file on the Windows filesystem NTFS has a set of permissions managed by the filesystem. Every NTFS file that WSL knows about (if mounted with -o metadata) acquires a completely parallel set of file permissions that "mirror" the NTFS permissions but can get out of sync. <ahref="https://devblogs.microsoft.com/commandline/chmod-chown-wsl-improvements/">All sorts of fun</a> results: <em>"With network file systems, DrvFs does not set the correct Linux permissions bits on a file; instead, all files are reported with full access (0777) and the only way to determine if you can actually access the file is by attempting to open it."</em>. This will be fixed by WSL2 which will have <ahref="https://docs.microsoft.com/en-us/windows/wsl/wsl2-ux-changes">an entirely separate filesystem</a>, a Virtual Hardware Disk (VHD). Which will introduce a quite different set of interesting problems.
<p>If you are disturbed by the instructions to produce an entirely different key for WSL1 to use when your PC already has a perfectly good PuTTy key installed on the server, then you are right. It is inelegant. But it works, the instructions are shorter and there are fewer things that go wrong. If you are terribly offended by that then you can set your PC up to use one key shared between WSL and normal-Windows as described in <ahref="https://devblogs.microsoft.com/commandline/sharing-ssh-keys-between-windows-and-wsl-2/">this October 2019 article</a>. (Don't set up a password on the key because then you don't need to install keychain.) But beware, this sort of thing goes out of date quite rapidly and WSL2 is looming.
<p>Links to useful articles to help you work this out for yourself:
<ul>
<li><ahref="https://www.hanselman.com/blog/CoolWSLWindowsSubsystemForLinuxTipsAndTricksYouOrIDidntKnowWerePossible.aspx">Cool WSL tricks</a> - running Windows commands from WSL environment and running Linux commands from Windows terminal.
<li><ahref="https://code.visualstudio.com/blogs/2019/09/03/wsl2">deep integration</a> - Don't use gitforwindows, install the linux git client in WSL2
<li><ahref="https://blog.anaisbetts.org/using-github-credentials-in-wsl2/">using-github-credentials-in-wsl2</a> - How to use gitforwindows and WSL to connect to GitHub.
<li><ahref="https://code.visualstudio.com/blogs/2019/09/03/wsl2">WSL2 & Visual Studio Code</a>
