From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95631 invoked by alias); 13 May 2018 15:46:06 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 95506 invoked by uid 89); 13 May 2018 15:45:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=smi, Hx-spam-relays-external:sk:smtp-ou, SYSTEM, H*Ad:D*ca X-HELO: smtp-out-no.shaw.ca Received: from smtp-out-no.shaw.ca (HELO smtp-out-no.shaw.ca) (64.59.134.12) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 13 May 2018 15:45:52 +0000 Received: from [192.168.1.100] ([24.64.240.204]) by shaw.ca with ESMTP id HtBtft2SzuYopHtBufEf4N; Sun, 13 May 2018 09:45:43 -0600 X-Authority-Analysis: v=2.3 cv=GopsBH9C c=1 sm=1 tr=0 a=MVEHjbUiAHxQW0jfcDq5EA==:117 a=MVEHjbUiAHxQW0jfcDq5EA==:17 a=IkcTkHD0fZMA:10 a=U6l2Ie19AAAA:8 a=w_pzkKWiAAAA:8 a=yMhMjlubAAAA:8 a=fAqEmcGJYTvyGYAJh2MA:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=u1xPsCyrYbr6myoU:21 a=wCC-TrTcxfuOMluE:21 a=QEXdDO2ut3YA:10 a=cGqI-nU3mX0A:10 a=YmmmDzbPQPlleAJrGTjh:22 a=sRI3_1zDfAgwuvI8zelB:22 Reply-To: Brian.Inglis@SystematicSw.ab.ca Subject: Re: Failure download cygwin References: <201805121507.w4CF7VD2018767@telford.daku.org> <7f49a650-4b02-275b-d200-a0c8704a532a@SystematicSw.ab.ca> <201805130957.w4D9vXir031126@telford.daku.org> To: cygwin@cygwin.com, david From: Brian Inglis Message-ID: Date: Sun, 13 May 2018 16:01:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <201805130957.w4D9vXir031126@telford.daku.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfAaMPUL8diY7wrXYdVJtIPC0Cxq6mP+anqX5K8vgqWZb9sDADAHUcUWDspYMA5kFn3penTOR3UCP5R7eJhpY7z3IYGZkKAKCp/IpAnRiR991aXT5bvuD juhrzpgg5J2hM5em9s/5rGc4W2H2PmhLXlhNBESCrq6I/x8mvh9RxF1ZwLHy84YrdJi6bKyY6HY5Fe5w5TL//CNWmgv+4b4uEWI= X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00168.txt.bz2 On 2018-05-13 03:57, david wrote: > At 09:20 AM 5/12/2018, Brian Inglis wrote: >> On 2018-05-12 09:06, david wrote: >> > I tried to install the full collection from cygwin 64-bit. Yes, I know "you >> > really don't want to do that", but nevertheless, I do. >> > Using three different download mirrors, I find a large number of packages >> > have failed. A partial list is given below. In the past, the download has >> > succeeded, and yes, it took hours. >> > Please advise. >> > My most recent download attempt was from >> > ftp://linux.rz.ruhr-uni-bochum.de/cygwin >> > Download failures: (partial list) >> ... >> You may be more successful if you preload your local package cache using e.g. >> wget -m, with some retry (and rate) limiting options, from your closest, lowest >> latency, fastest transfer rate, http mirror. > I followed your suggestion, but still had problems.  After some more > experiments, I figured out that the file names were too long, and thus the > downloads failed.  Unfortunately, this was not diagnosed by "setup", which, in > my opinion, should not allow a download to start if the file names won't fit in > the current Windows.  I assume (perhaps incorrectly), that there is a limit to > package name length. > For example, I used as the directory >   d:\arch\archiven\cygwin.2.10.0 > and the selection of the download site made it > d:\arch\archiven\cygwin.2.10.0\ftp%3a%2f%2flinux.rz.ruhr-uni-bochum.de%2fcygwin%2f > which is getting pretty long. > Thanks for the download pointer; it helped me isolate the problem. Should not be any issue if you are on NTFS and using supported Windows - my Windows package cache path for years has prefix length 110 chars: C:\...\.....\cygwin64\var\cache\setup\packages\https%3a%2f%2f.......................%2fmirror%2fcygwin.com%2f\ and similar on Cygwin32, kept to support package builds. Cygwin uses some of the approaches mentioned below to support longer Unix-like paths: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx "The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path". ... A registry key allows you to enable or disable the new long path behavior. To enable long path behavior set the registry key at HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD). The key's value will be cached by the system (per process) after the first call to an affected Win32 file or directory function (list follows). The registry key will not be reloaded during the lifetime of the process. In order for all apps on the system to recognize the value of the key, a reboot might be required because some processes may have started before the key was set. ... You can also enable the new long path behavior per app via the manifest: true " I don't even have long paths enabled: $ xxd -g4 /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/FileSystem/LongPathsEnabled 00000000: 00000000 but now I know about it, I am looking for more info about whether to set it. -- 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