A work in progress.
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.
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.
Anything where the file upload and download is done via the verson control client software works really well.
Most Windows software that we recommend "just works" if you have set up PuTTy and have done the key-pair setup and are running a local ssh agent (pagent) automatically at boot up on your laptop.
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).
Some software (such as FIlezilla) defaults to using the local agent and it "just works".
Linux allows characters in filenames which Windows doesn't. There are also apparently normal filenames which Windows rejects (such as "CON") for historical reasons. Linux filenames are case-senstitive and Windows filenames aren't: beware.
Linux people like to use links. 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.
The links you are most likely to come across are that what looks like
/home/expo/expoweb is really just a link to the folder /home/expo/repositories/hg/expoweb,
and that
expoweb/essentials.gpx
is a link to the file /home/expo/expofiles/gpslogs/essentials/essentials2019.gpx
But that example is in the ::expoweb:: 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 seem to have any hard links anywhere.
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.
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.
What is even more irritating is that Filezilla displays an link (essentials.gpx 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.
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.
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.
So on a machine with WSL enabled, create an ordinary cmd window and get into the WSL environment using the wsl command:
D:\CUCC-Expo\expoweb\ wsl
which puts you into the WSL environment with a new command prompt, e.g.
philip@Muscogee:/mnt/c/Users/Philip$
and now you can setup keys in the same way as you would on a Linux machine using ssh-keygen:
$ ssh-keygen -C "philip@muscogee-wsl" Generating public/private rsa key pair. Enter file in which to save the key (/home/philip/.ssh/id_rsa): id_rsa_wsl Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in id_rsa_wsl. Your public key has been saved in id_rsa_wsl.pub. The key fingerprint is: SHA256:ySs0YD5IG2ZD50+riUDHWosNq+WJdqpkDlINXh709r0 philip@muscogee-wsl The key's randomart image is: +---[RSA 2048]----+ | . o | | ..+ . | | oB+* + | |.=O%.* + o | |.+*o= = S . | |.* o = . . . | |=++.o . . E | |B o . | |oo | +----[SHA256]-----+ $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).
Now you have to complete the key-pair setup 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.
Now finally you can use all the usual command line tools at yor wsl command line to communicate with the server with ssh, scp, rsync, such as:
rsync -nazv --delete-after --prune-empty-dirs expo@expo.survex.com:expofiles/ expofiles
So here is the current wild frontier. Currently these are the ways to get a terminal window which might work:
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. All sorts of fun results: "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.". This will be fixed by WSL2 which will have an entirely separate filesystem, a Virtual Hardware Disk (VHD). Which will introduce a quite different set of interesting problems.
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 this October 2019 article. (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.
Links to useful articles to help you work this out for yourself:
When things go wrong when trying to sort this out, you may find these pages useful. I did. file-system-improvements-to-the-windows-subsystem-for-linux/ id-rsa-pub-file-ssh-error-invalid-format key-load-public-invalid-format ssh-error-loading-key-id-rsa-invalid-format chmod-chown-wsl-improvements mount-usb-drives-windows-subsystem-for-linux VS Code and WSL ssh command line
Now return to the Your Laptop page to configure all the rest of the software you need.