From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sa-prd-fep-044.btinternet.com (mailomta12-sa.btinternet.com [213.120.69.18]) by sourceware.org (Postfix) with ESMTPS id DA3E33857C57 for ; Wed, 26 Aug 2020 20:55:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DA3E33857C57 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=jon.turney@dronecode.org.uk Received: from sa-prd-rgout-002.btmx-prd.synchronoss.net ([10.2.38.5]) by sa-prd-fep-044.btinternet.com with ESMTP id <20200826205545.RLID3440.sa-prd-fep-044.btinternet.com@sa-prd-rgout-002.btmx-prd.synchronoss.net> for ; Wed, 26 Aug 2020 21:55:45 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com X-Originating-IP: [31.51.205.206] X-OWM-Source-IP: 31.51.205.206 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddvvddgudehvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnheptdevveffteelgfekieevieekleevvdehtddvgfdvgefgjedujedviedugeeghfefnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepfedurdehuddrvddthedrvddtieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddrudduudgnpdhinhgvthepfedurdehuddrvddthedrvddtiedpmhgrihhlfhhrohhmpeeojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhequceuqfffjgepkeeukffvoffkoffgpdhrtghpthhtohepoegthihgfihinhestgihghifihhnrdgtohhmqe X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.111] (31.51.205.206) by sa-prd-rgout-002.btmx-prd.synchronoss.net (5.8.340) (authenticated as jonturney@btinternet.com) id 5ED9AA6E0DA7CD57 for cygwin@cygwin.com; Wed, 26 Aug 2020 21:55:45 +0100 Subject: Re: Forcing setup.exe not to create WSL symlinks To: The Cygwin Mailing List References: <875z95tg5c.fsf@Rainer.invalid> From: Jon Turney Message-ID: <1f4a80f7-0e14-1641-3fce-317ac2a6dd00@dronecode.org.uk> Date: Wed, 26 Aug 2020 21:55:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <875z95tg5c.fsf@Rainer.invalid> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NONE, 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 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: Wed, 26 Aug 2020 20:55:49 -0000 On 26/08/2020 19:29, Achim Gratz wrote: > Michael Wild via Cygwin writes: >> Is there a way to disable WSL symlinks when installing Cygwin with >> setup.exe? Problem is that Docker on Windows apparently doesn't support >> them (see https://github.com/moby/moby/issues/41058). I would like to use a As a comment in that issue identifies [1], this isn't actually an issue with setup per se, but the post-install scripts it runs. [1] https://github.com/moby/moby/issues/41058#issuecomment-674402289 setup itself always creates symlinks when unpacking packages as traditional Cygwin symlinks (a plain file containing a magic value and the path, which are only understood by Cygwin). (Setup probably should match Cygwin's behaviour and/or have an option to specify how it creates symlinks) >> custom Docker image for GitHub Actions to reproducibly build my packages >> but am failing to build the base image because of this. > > That description is not very clear. If the symlinks are created during > postinstall, then they should obey the value of CYGWIN environment that > is in effect at that time. If so, then the behaviour should start > appearing with cygwin-3.1.5, which is the first release that has the > code supporting these (and makes them the default). I'm not aware that > the behaviour of setup.exe has changed in that respect recently, but I > haven't checked thoroughly. 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)