expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2025-12-09 07:14:36 +00:00
Code Issues Packages Projects Releases Wiki Activity

fixing links in different folders

Browse Source
This commit is contained in:
Philip Sargent
2020-04-26 23:27:38 +01:00
parent 6702081779
commit 75c2abeef0
5 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
handbook/computing/winlaptop.html
View File

@@ -153,7 +153,7 @@ Now finally you can use all the usual command line tools at yor wsl command line
<h4>WSL1 tricks and tips</h4>
<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. <a href="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 <a href="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>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 are fundamentally different things and are never in sync in any sense. <a href="https://devblogs.microsoft.com/commandline/chmod-chown-wsl-improvements/">All sorts of fun</a> results. This will be fixed by WSL2 (expected May 2020) which will have <a href="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 <a href="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.