From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) by sourceware.org (Postfix) with ESMTPS id 921F93870900 for ; Thu, 27 Aug 2020 12:49:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 921F93870900 Received: by mail-ot1-x344.google.com with SMTP id r8so4260616ota.6 for ; Thu, 27 Aug 2020 05:49:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=p8ayAh+TqsxGlZEFR0LmdMkwIx7Vz2dcageNvE0yNhI=; b=FXDbEKxLEXwVFRl7iRwY2ha0DwKM7iX3vhGmBkGWxFgzeLZcuTnTprg9BBlePCF6Xp c0ndEDG05VwnAIOW+RDaqVvQCF8jNJeZsKYGhcpj/uMwB2AXI4pc78yjqHT/Lb3UHu1Z D4jkmi7dsk8LTAvXos0hTvwgwMzqrFkyGgW61FJjdUgz4x9atD/vx6zgUFWty0ZyG0Pb otDMRMdFTFfUSur7oHxsNomtg2Xv84ChqdqbhwW78QRSf7XurNMTLMvlPmywIsx5JNUF vatK1HPNPhOaNZ9xD0QicScOvPQsxMx/Uihox/7rLinIC2LUebRUG8c2ECNNm6y8FJyC 6hIA== X-Gm-Message-State: AOAM532V9MaQxBOvQSi0INXe3RrgduLfegluL1GJD9A+69RP3m0ilYZt NbPoW+S2VLs3h/tyOJo9b9he7os9hZ8qSoX98wWpbYu+EHA= X-Google-Smtp-Source: ABdhPJzL2t+Qschx+E0r9yrbHmm+SLjJLG62eVU5jcwIAkuKS2/zvXsJ/SQjWzA3eBkLX+6fN7aeZYMygKuWiLwNRaM= X-Received: by 2002:a9d:ac3:: with SMTP id 61mr14040443otq.23.1598532550589; Thu, 27 Aug 2020 05:49:10 -0700 (PDT) MIME-Version: 1.0 References: <875z95tg5c.fsf@Rainer.invalid> <1f4a80f7-0e14-1641-3fce-317ac2a6dd00@dronecode.org.uk> <20200827090010.GZ3272@calimero.vinschen.de> In-Reply-To: From: Michael Wild Date: Thu, 27 Aug 2020 14:48:51 +0200 Message-ID: Subject: Re: Forcing setup.exe not to create WSL symlinks To: The Cygwin Mailing List X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 12:49:13 -0000 On Thu, Aug 27, 2020 at 11:44 AM Michael Wild wrote: > > On Thu, Aug 27, 2020 at 11:02 AM Corinna Vinschen wrote: > >> On Aug 27 07:48, Michael Wild via Cygwin wrote: >> > On Wed, Aug 26, 2020 at 10:57 PM Jon Turney wrote: >> > >> > > >> > > It turns out to be the case that setup doesn't propagate the CYGWIN >> > > environment variable into the environment for scripts it runs, so >> > > setting that isn't going to make any difference. That should probably >> > > be considered a bug. >> > > >> > > However, even if that's fixed, there's no value for winsymlinks in >> > > CYGWIN env var to specify the behaviour of Cygwin 3.1.4 and previous >> > > (i.e. always create traditional symlinks, don't use WSL symlink >> reparse >> > > points) >> > > >> > >> > Thanks Jon for the elaboration. Isn't winsymlinks=lnk supposed to do >> this >> > per the documentation? Could Corinna be convinced to include an option >> > where this can be done? To be honest, my hopes are greater to get this >> > worked-around in a useful timeframe from the Cygwin side than getting >> the >> > proper fix into Docker. >> >> Isn't it sufficient to fix setup so you can create lnk-style symlinks in >> your scenario? The CYGWIN env variable and the number of options is >> such a mess. >> >> >> Corinna >> > > I am right now modifying setup to not sanitize CYGWIN away when invoking > the post-install scripts and then will report back. > > Michael > Hmm, OK, changing script.cc to not strip out CYGWIN is trivial. But the harder part is that main.cc uses ShellExecuteEx() with SHELLEXECUTEINFO.verb set to "runas" in order to re-run setup elevated. This resets all environment variables back to default. In my instance I can circumvent this by passing --no-admin and running from an elevated shell where CYGWIN is set already. And indeed, this works and resolves my Docker problem. I attached this fix as a patch. But on the other hand, I find this behavior to be a bit confusing. However, I don't see an easy way of resolving the "runas" issue, because it is by design. An option would be that the calling process passes the CYGWIN variable as a command line argument to the elevated process. But that is also ugly. What do you guys think? Michael