improve windows support for symlinks

[timotheecour]

The fact that symlinks are poorly supported on windows affects even non-windows users, for example see dom96/choosenim#189 (choosenim uses shims instead of symlinks, which can cause issues). Even if window's symlinks aren't semantically equivalent with posix symlinks (and aren't supported as well for older windows versions), we should still offer the best possible semantics the platform offers.

Examples

• bug1: in stdlib/os: handle symlinks in copy/move functions #16709, copyFile doesn't honor cfSymlinkAsIs even though it's possible via COPY_FILE_COPY_SYMLINK (refs stdlib/os: handle symlinks in copy/move functions #16709 (comment))

• bug2: expandSymlink is a noop on windows even though it's possible via GetFinalPathNameByHandle refs https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfinalpathnamebyhandlea?redirectedfrom=MSDN https://stackoverflow.com/questions/221417/how-do-i-programmatically-access-the-target-path-of-a-windows-symbolic-link?noredirect=1&lq=1
  (refs: Please make expandSymlink() work in Windows! #3023)
  => PR fix #3023 make expandSymlink work on Windows #17289

• bug3: createSymlink docs are misleading: Some OS's (such as Microsoft Windows) restrict the creation of symlinks to root users (administrators). doesn't reflect the fact that if developper mode is enabled, you don't need to run the code as admin

• bug4: checkSymlink is disabled on windows but really this (private) proc should be removed since it's redundant with symlinkExists (which is supported on windows)
  => remove private checkSymlink (redundant with symlinkExists) #16785

• bug5: maybe we could add a feature detection proc proc supportsOsFeature*(feature: Feature): bool which detects whether your OS (or particular version of windows) supports some feature, eg creating a symlink, or creating a symlink without root access etc

• bug6: findExe doesn't honor followSymlinks on windows

• bug7: (only mildly related to this issue) in moveFile, when tryMoveFSObject fails, moveFile silently doesn't raise

• bug8: expandFilename doesn't seems to resolve symlinks (unlike on posix); GetFinalPathNameByHandleA seems like what should be used (but should be called through expandSymlink)

• bug9: I'm not sure whether symlinkExists is correct; according to https://stackoverflow.com/questions/1485155/check-if-a-file-is-real-or-a-symbolic-link#comment69012157_26473940 this could have false positives; that stackoverflow thread contains correct answers; IIUC checking IO_REPARSE_TAG_SYMLINK is also needed

Check out the returned data structure to inspect. The reparse tag will tell you if it is a junction point or symbolic link. This may be all you want to do.

Additional Information

1.5.1 2b5841c

links

• https://www.wintellect.com/non-admin-users-can-now-create-symlinks-windows-10/
• https://docs.microsoft.com/en-us/windows/win32/fileio/symbolic-link-effects-on-file-systems-functions
• https://security.stackexchange.com/questions/10194/why-do-you-have-to-be-an-admin-to-create-a-symlink-in-windows