Re: Failure download cygwin

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

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:
<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings
xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
</application>"

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