From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117126 invoked by alias); 21 Jan 2017 19:28:01 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 117066 invoked by uid 89); 21 Jan 2017 19:28:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=Wolff, wolff, halfway, remembered X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.17.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 21 Jan 2017 19:27:50 +0000 Received: from [192.168.178.45] ([95.91.244.74]) by mrelayeu.kundenserver.de (mreue103 [212.227.15.183]) with ESMTPSA (Nemesis) id 0LnDWH-1c36A22pSP-00hNZ2 for ; Sat, 21 Jan 2017 20:27:47 +0100 Subject: Re: network installation failed, new diagnostics To: cygwin-apps@cygwin.com References: <0b0dd363-3cb3-3019-142b-8ded91df817e@towo.net> <20170116130009.GA16058@calimero.vinschen.de> From: Thomas Wolff Message-ID: Date: Sat, 21 Jan 2017 19:28:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170116130009.GA16058@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-UI-Out-Filterresults: notjunk:1;V01:K0:NEj2xBsqd9Y=:cgfIFARybEmPqf943r2GCb GwJ4wsJMe9CcE2NMNlwe4ihpUBcf5rR2Sd3HuwApVQjpIQQaK6FrRQLJxqznrehdsFArWfyO0 +jx+q4Bx0T152xcWrmy8D5y5Nk+e92q8N+Oui7LdgyUfEYK4fGey/TQAWO3IYjEbRUdO9M8Vn YWMD0YbpnoW5/gJ/uBjNYfY+nBziYSCILqoYWA5HnA/Bj2zDaaW9UNDT+ybcSHuyK3aq+Hzc/ B7ej32ZcoLbmXor5bjiXc0I06SS3MqZzFbtKbUXTR9IeZnp3SlvDxYcj7CM5mHh5rErivZmCe RDIgmIqB+2pWtwmL6D0Cr6r7ygtoB8ZCevsJuNg9KRf7fVLRC9mlBnggvxPjCWBvQ+WCdJUPm 27P+uX1Nw2bG8die/0jlL7JifQTAPyFjHfiLu+uPpNiSXlwOKg4h5zwmgtEOhV4NOJB5k54ZC 9RelRGYrVGFdKkEbQejhPXhxo246RCBZc+kxQH3KOKW04RQtfe0cvMhqcwKFlr8aBYK28raxy 8Wihi7KSPMJ73yKMWx+fzzkoN8M8IljJGyy8E5exvFJmw1m3Lpg5EZWRnG8hBO9zHjm+BX9j1 76FTuJAWb8aSjYp7QIu9RZr4zpSGG9svbfh4Ve0wHKUXPFFDjgexkggAHPI+jxnIoW0fCA2ou 2WX3DGFM+uW8D50GI+SpOd2CYWwVQzNzJ6Vy+/aGRAwAb2SbmEWTXBfugQ0zgptnIpE7F0s41 m272UG7DlC7pwKU+ X-SW-Source: 2017-01/txt/msg00034.txt.bz2 Am 16.01.2017 um 14:00 schrieb Corinna Vinschen: > On Jan 15 23:49, Thomas Wolff wrote: >> Concerning https://cygwin.com/ml/cygwin-apps/2016-07/msg00021.html, >> I have some new insights; first, I tried with a range of older versions of >> setup.exe (from the cygwin time machine) but all failed, so its not a >> regression as I had speculated. >> >> Then I tried to run setup.exe without elevation, by elevating before >> (running mintty as adminstrator). So I noted (and could have checked this >> earlier...) that the involved network mounts were not fully established: >> >> mount (unelevated): >> L:/TGI/cygwin7 on / type ntfs (binary,auto) >> L: on /cygdrive/l type ntfs (binary,posix=0,user,noumount,auto) >> ... >> >> mount (elevated): >> //141.64.144.100/Labormaterial/TGI/cygwin7 on / type ntfs (binary,auto) >> ... >> >> After fixing the mount: >> net use L: '\\141.64.144.100\Labormaterial' >> >> setup.exe works as expected. >> >> Not being familiar with details of Windows permission stuff and >> user-specific mounts myself, does this help to analyse and maybe even fix >> the situation? > This is an UAC issue, not a Cygwin setup issue. When elevating, the > mounts are not propagated to the elevated processes. There's a > documented registry value enabling the supposedly dangerous propagation > of mount point to elevated processes, but I don't knowe it off the top > of my head. You may want to search MSDN. On my home systems, mounts are not propagated at all, I wouldn't expect setup to work then, agreed. However, on that lab systems, the mounts are kind of half-way propagated to elevated mode. They and visible and accessible using the network path (cd //141.64.144.100/Labormaterial/TGI; ...). Now setup.exe apparently has remembered the network path for the Local Package Directory which appears as \\141... in the respective setup.exe screen, and in fact it does all the downloading to that directory, it just fails during later installation which corresponds to the Root Directory path appearing in drive format (L:...) in the respective setup.exe screen. I'm just thinking if setup.exe would handle the Root Directory path in the same way as it handles the Local Package Directory path, the setup should work in that case. ------ Thomas