From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: cygwin@cygwin.com
Subject: Re: Windows 10 Creators Update and Symlinks
Date: Mon, 24 Apr 2017 04:16:00 -0000 [thread overview]
Message-ID: <3e2df893-9813-2f1b-ad0b-f7e6fa5cdc19@SystematicSw.ab.ca> (raw)
In-Reply-To: <60bf66d9-d467-3cac-72f9-7823d1c1c32a@teco.edu>
On 2017-04-23 03:26, Till Riedel wrote:
> Am 13.04.2017 um 0:29 schrieb Jeffrey Altman:
>> When Developer mode is enabled the elevation requirement for
>> symlink creation is disabled:
>> https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/#DXz6icKZOkEozgYR.97
>> This was necessary for symlink creation within WSL to work.
> I was really excited to hear this!
> I tried to export CYGWIN="winsymlinks:nativestrict" and create
> symlink without elevation and failed on cygwin 2.8.0 (checked that
> "cmd /C mklink" works as expected in Windows 10 Creators Update
> Developer Mode).
> Any ideas if there are any extra checks that lead to "Operation not
> permitted"?
> Windows seemingly even allows symlinks to nonexistent files (I
> somehow think there was a problem with that in the past). For me
> personally this would a strong reason to switch to real symlinks.
Artcile states:
CreateSymbolicLink
To enable the new behavior when using the CreateSymbolicLink API,
there is an additional dwFlags option you will need to set:
Value Meaning
SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE
0x2 Specify this flag to allow creation of symbolic links when the
process is not elevated
So Cygwin patches are required to winsymlinks:native/strict handling
in winsup/w32api/include/winbase.h (which may be owned by mingw):
#define SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE 0x2
and in winsup/cygwin/path.cc(symlink_native) like:
/* Try to create native symlink. */
if (!CreateSymbolicLinkW (final_newpath->Buffer, final_oldpath->Buffer,
#ifdef SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE
SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE |
#endif
(win32_oldpath.isdir ()
? SYMBOLIC_LINK_FLAG_DIRECTORY : 0)))
but may need W10 build 14972 checks, and any privilege checks disabled.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
next prev parent reply other threads:[~2017-04-23 15:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4b5447f2-a1fe-925e-5e3d-6692347374ad@kit.edu>
2017-04-23 21:13 ` Till Riedel
2017-04-24 4:16 ` Brian Inglis [this message]
2017-04-24 16:09 ` Corinna Vinschen
2017-04-24 20:58 ` Corinna Vinschen
2017-04-25 1:46 ` David Macek
2017-04-25 5:26 ` Corinna Vinschen
2017-04-13 13:27 Jeffrey Altman
2017-04-23 22:09 ` Thomas Wolff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3e2df893-9813-2f1b-ad0b-f7e6fa5cdc19@SystematicSw.ab.ca \
--to=brian.inglis@systematicsw.ab.ca \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).