Stuck with incomplete Cygwin installation

[Daniel Friedman]

Quick summary: I'm stuck being unable to achieve a working Cygwin
installation on a machine that formerly had one.

I recently tried to update Cygwin packages using setup, and developed
the "bash: fork: retry: Resource temporarily unavailable" issue which
many online posts indicate  can be cured with a "rebaseall" procedure.
That procedure didn't work for me, so I've uninstalled/reinstalled
Cygwin multiple times, and  can't achieve a complete  Cygwin
installation. I now face the following issues after running setup:
* As part of the postinstall routine operated by the setup program,
the base-files-mketc.sh and base-files-profile.sh postinstall scripts
both exit abnormally (error code 254 for each).
* While /home is generated by setup, a home directory for me within
/home does not get created.
* /etc/skel also does not get created.
* Upon accessing a bash shell environment by opening a Cygwin terminal
(mintty) using the desktop shortcut created by the setup program, I
see the PATH variable does not include any directory within the Cygwin
installation. Specifically, my Cygwin installation is rooted at
C:\cygwin64 and  PATH does not include any directory rooted at
/cygdrive/c/cygwin64 (such as /cygdrive/c/cygwin64/bin).

I''ve tried the following multiple times to address these issues, with
the same unsuccessful outcomes as described above:
* Removed Cygwin per
https://cygwin.com/faq/faq.html#faq.setup.uninstall-all. (I've saved
my home directory from the last successful Cygwin installation, but
haven't copied any files from it to the new installations.) Note: At
least since attempting reinstallation, if I close all Cygwin terminal
windows, I do not see any Cygwin-related processes running in the
Windows Task Manager.
* Reinstalled Cygwin as administrator, as well as tried using setup's
--noadmin and --disable-buggy-antivirus command-line options.
* Used different Cygwin download sites (selected within the setup
program). I didn't expect this would help, but tried anyway.
* Installed only default packages (and the packages they depend on).
* Speculating it might help, I tried installing the cygrunsrv package
despite setup indicating it's not needed by default. Indeed, this
approach didn't help. Further: While cygrunsrv files do get installed
on the disk (e.g. /usr/sbin/cygserver.exs exists) there's no evidence
a related service is being installed in a way Windows
recognizes--there's nothing Cygwin-related listed by Windows'
application for managing services, services.msc.
* '/usr/bin/rebaseall -v' -- the  command appears to run successfully,
but re-running setup afterward does not address the issues noted
above, and the two postinstall scripts fail again when setup runs
them.
* '/usr/bin/rebase-trigger full' -- same effect, upon running setup,
as described in previous line.
* Used Windows facility to delete read-only permission on my
installation directory (C:\cygwin64) and for subdirectories nested
within it...and re-ran setup afterward.
* Attempted to manually run the base-files-mketc.sh and
base-files-profile.sh postinstall scripts from the command line. These
attempts always yield errors of the following kind (the numbers, other
than "errno 11", vary):
--- begin typical error message ---
1152878 [main] sh 304 fork: child 27120 - died waiting for dll loading, errno 11
./base-files-mketc.sh: fork: retry: Resource temporarily unavailable
--- end typical error message ---
Additionally, running setup after attempting to run these scripts
manually causes not only the scripts to again fail when invoked by
setup.exe, but the 0p_000_autorebase.dash script also fails, with exit
code 2.
* Re-downloaded the setup program.

Some more details:
* Windows 10 machine
* Cygwin setup.exe version 2.877 (64 bit)
* I've attached /var/log/setup.log.full from my most recent
installation attempt, in case it might help.
* I have extensive but somewhat limited administrator rights on this
Windows machine; in particular, I can't suspend or disable the
anti-virus software. However, I've never before had a related problem
with Cygwin--not on this machine I've had since August 2016, and not
on any other machine with same limited admin rights I've had over the
past 7+ years. This all strongly suggests to me (IMHO) the anti-virus
software, and my limited admin rights, are not interfering with the
Cygwin installation.

After hours of searching the web and attempting multiple
reinstallations, I'm sorry to lean on the community for help, but I'm
really at wits end. I'm willing to try new ideas, and appreciate any
suggestions.

Thanks very much in advance,
--Daniel


setup.log.full
Description: Binary data

--
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

Re: yasm: man7 packaging

[David Stacey]

On 09/02/17 05:18, Yaakov Selkowitz wrote:
Wrt yasm's manpages, yasm(1) references several yasm_*(7) pages, which 
are packaged with yasm-devel instead of yasm.  As these describe 
concepts rather than APIs (unlike man3), could you please move them over?


Sure - I'll try to take a look later today. Thanks for the tip!

Dave.


--
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

yasm: man7 packaging

[Yaakov Selkowitz]

David,

Wrt yasm's manpages, yasm(1) references several yasm_*(7) pages, which 
are packaged with yasm-devel instead of yasm.  As these describe 
concepts rather than APIs (unlike man3), could you please move them over?


--
Yaakov

--
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

Re: cygpath -w converts relative paths to absolute windows paths

[Roger Qiu]

Hi Andrey,

That was probably true in the past, but no longer!

I just tested this: `mklink /D testlink "..\All Users"` in cmd and then 
I went to Cygwin ZSH, and ran `ll`.


This showed me: `testlink -> '../All Users'/`.

Up one directory relative links do work on Windows! This is a directory 
symbolic link, which is superior to directory junctions.


Regardless of directory junction support (which I didn't test), I think 
`cygpath` should give the right results, when I don't specify an 
absolute path, I really mean give me the windows version of the relative 
path.


Now maybe there's some backwards compatibility issues, then perhaps a 
flag that can be set to mean `--really-relative`.


Thanks,

Roger

On 8/02/2017 2:30 AM, Andrey Repin wrote:

Greetings, Roger Qiu!


Hi,
I've found that `cygpath --windows '../` will give back an absolute
windows path.
I thought this would only happen if you provide the `--absolute` flag,
or when the path is a special cygwin path.

".." is a special path, that can't be safely converted.
In all cases, using absolute path is preferred for many reasons.


But this occurs just for normal directories.
I have come across a situation where I need to convert ntfs symlinks to
unix symlinks and back. Sometimes these symlinks have relative paths
them. Now by using cygpath --windows, I get back absolute paths, which
means the integrity of the symlink isn't preserved.
Can `cygpath --windows '../directory'` give back `..\directory` for
paths aren't special cygwin paths? These relative backslashes are
supported in Windows right now.

AFAIK, Windows do not support relative junction points.




--
Founder of Polycademy
http://polycademy.com/
+61420925975


--
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

Re: -displayfd outputting some garbage?

[Jon Turney]

On 08/02/2017 01:02, Matt D. wrote:

On 2/7/2017 7:46 PM, Matt D. wrote:

I have an xinit script which outputs the display id to a file with the
following option:

xinit .. -displayfd 3 3>$HOME/.display


Thanks for reporting this.

For future issues, can I ask you to use the cygwin list, per [1]

[1] https://cygwin.com/ml/cygwin-xfree-announce/2015-03/msg1.html

I hope you mean ' xinit -- -displayfd 3 3>$HOME/.display'


This outputs correctly '0' but appends 0x00 and 0x0A. Why is it
outputting a null byte and this 0x0A?


Yeah, this seem to be a bug in xinit (which needs to insert itself into 
the displayfd pipeline to learn the display number for it's own purposes)


$ X -displayfd 3 3>~/.display
[...]
$ xxd ~/.display
: 300a 0.

$ xinit -- -displayfd 3 3>~/.display
[...]
$ xxd ~/.display
: 3000 0a  0..


This is causing issues where I try to perform:

echo $(cat .display)

Which results in:

bash: warning: command substitution: ignored null byte in input
0


This warning is new in bash 4.4, I think.

I think this is a just a warning though, and shouldn't actually cause 
any issues?


--
Jon Turney
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

[PATCH] Cygwin: create separate bits/byteswap.h

[Yaakov Selkowitz]

Match glibc behaviour to expose the public bswap_* macros only with an
explicity #include ; #include'ing  should not expose
them.

Signed-off-by: Yaakov Selkowitz 
---
 winsup/cygwin/include/bits/byteswap.h | 37 +++
 winsup/cygwin/include/byteswap.h  | 25 +--
 winsup/cygwin/include/endian.h| 26 
 3 files changed, 51 insertions(+), 37 deletions(-)
 create mode 100644 winsup/cygwin/include/bits/byteswap.h

diff --git a/winsup/cygwin/include/bits/byteswap.h 
b/winsup/cygwin/include/bits/byteswap.h
new file mode 100644
index 000..20ed5bb
--- /dev/null
+++ b/winsup/cygwin/include/bits/byteswap.h
@@ -0,0 +1,37 @@
+/* bits/byteswap.h
+
+This file is part of Cygwin.
+
+This software is a copyrighted work licensed under the terms of the
+Cygwin license.  Please consult the file "CYGWIN_LICENSE" for
+details. */
+
+#ifndef _BITS_BYTESWAP_H
+#define _BITS_BYTESWAP_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+static __inline unsigned short
+__bswap_16 (unsigned short __x)
+{
+  return (__x >> 8) | (__x << 8);
+}
+
+static __inline unsigned int
+__bswap_32 (unsigned int __x)
+{
+  return (__bswap_16 (__x & 0x) << 16) | (__bswap_16 (__x >> 16));
+}
+
+static __inline unsigned long long
+__bswap_64 (unsigned long long __x)
+{
+  return (((unsigned long long) __bswap_32 (__x & 0xull)) << 32) | 
(__bswap_32 (__x >> 32));
+}
+
+#ifdef __cplusplus
+}
+#endif
+#endif /* _BITS_BYTESWAP_H */
diff --git a/winsup/cygwin/include/byteswap.h b/winsup/cygwin/include/byteswap.h
index 5e3f221..05bb5ca 100644
--- a/winsup/cygwin/include/byteswap.h
+++ b/winsup/cygwin/include/byteswap.h
@@ -9,33 +9,10 @@ details. */
 #ifndef _BYTESWAP_H
 #define _BYTESWAP_H
 
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-static __inline unsigned short
-__bswap_16 (unsigned short __x)
-{
-  return (__x >> 8) | (__x << 8);
-}
-
-static __inline unsigned int
-__bswap_32 (unsigned int __x)
-{
-  return (__bswap_16 (__x & 0x) << 16) | (__bswap_16 (__x >> 16));
-}
-
-static __inline unsigned long long
-__bswap_64 (unsigned long long __x)
-{
-  return (((unsigned long long) __bswap_32 (__x & 0xull)) << 32) | 
(__bswap_32 (__x >> 32));
-}
+#include 
 
 #define bswap_16(x) __bswap_16(x)
 #define bswap_32(x) __bswap_32(x)
 #define bswap_64(x) __bswap_64(x)
 
-#ifdef __cplusplus
-}
-#endif
 #endif /* _BYTESWAP_H */
diff --git a/winsup/cygwin/include/endian.h b/winsup/cygwin/include/endian.h
index a17ff99..5a43ad0 100644
--- a/winsup/cygwin/include/endian.h
+++ b/winsup/cygwin/include/endian.h
@@ -35,17 +35,17 @@ details. */
 
 #if __BSD_VISIBLE
 
-#include 
+#include 
 
 #if __BYTE_ORDER == __LITTLE_ENDIAN
 
-#define htobe16(x) bswap_16(x)
-#define htobe32(x) bswap_32(x)
-#define htobe64(x) bswap_64(x)
+#define htobe16(x) __bswap_16(x)
+#define htobe32(x) __bswap_32(x)
+#define htobe64(x) __bswap_64(x)
 
-#define be16toh(x) bswap_16(x)
-#define be32toh(x) bswap_32(x)
-#define be64toh(x) bswap_64(x)
+#define be16toh(x) __bswap_16(x)
+#define be32toh(x) __bswap_32(x)
+#define be64toh(x) __bswap_64(x)
 
 #define htole16(x) (x)
 #define htole32(x) (x)
@@ -67,13 +67,13 @@ details. */
 #define be32toh(x) (x)
 #define be64toh(x) (x)
 
-#define htole16(x) bswap_16(x)
-#define htole32(x) bswap_32(x)
-#define htole64(x) bswap_64(x)
+#define htole16(x) __bswap_16(x)
+#define htole32(x) __bswap_32(x)
+#define htole64(x) __bswap_64(x)
 
-#define le16toh(x) bswap_16(x)
-#define le32toh(x) bswap_32(x)
-#define le64toh(x) bswap_64(x)
+#define le16toh(x) __bswap_16(x)
+#define le32toh(x) __bswap_32(x)
+#define le64toh(x) __bswap_64(x)
 
 #endif /*__BYTE_ORDER == __BIG_ENDIAN*/
 
-- 
2.8.3

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Thomas Wolff]

Am 08.02.2017 um 19:34 schrieb Achim Gratz:

Thomas Wolff writes:

Further comments welcome, and it's Achim's turn to provide further
diagnostics input as requested in another mail. It could also be that
screen or tmux simply make invalid assumptions about the setting of
Wraparound modes.

That will take a while.  I'll have to set up something at home
specifically with the goal of reproducing the error.  At the moment it
looks like some sort of race between decisions made at different levels
of the stack mintty / tmux / mosh / screen since so far I've not been
able to reproduce if I take out one of these.

Are earlier versions of mintty, specifically the last versions of the
2.6 series, still available somewhere?
You can download older sources from 
https://github.com/mintty/mintty/releases and build them yourself.
Older versions may need some source or makefile tweaks to compile, I 
should publish my notes about this.



I'm almost certain that these
sort of things didn't happen before October or November last year.  Of
course it might have been another update of the other programs involved
as well.
I would suspect the latter as there have not been recent changes (since 
2.2.1) in the actual terminal emulation.


Actually I have found a bug in the combination of auto wraparound mode 
with scrolling region margins and origin mode.

Once fixed, that could even affect the issue, we'll see.

--
Thomas

--
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

Re: cygpath -w converts relative paths to absolute windows paths

[Thomas Wolff]

Hi Andrey,

Am 08.02.2017 um 11:54 schrieb Andrey Repin:

Greetings, Thomas Wolff!


Am 07.02.2017 um 16:30 schrieb Andrey Repin:

Greetings, Roger Qiu!


I've found that `cygpath --windows '../` will give back an absolute windows 
path.
...

".." is a special path, that can't be safely converted.

How is the special meaning of ".." so much different in Windows than in
Cygwin/Linux/POSIX that it could not be mapped?
Things like dir .., cd .., type ..\sub\file all work comparably.

Comparable? May be. Predictable?
https://bugs.php.net/bug.php?id=73797
I don't know what __DIR__ is supposed to mean in PHP. Anyway, handling 
".." is not predictable even within Linux/Cygwin, you could see 
something like:

> ls dir1/file
dir1/file
> cd dir2
> ls ../dir1/file
No such file or directory

(if dir2 is a link), or can have surprising effects of cd vs. cd -P.
I don't see how that should exclude ".." from being transformed to ".." 
by cygpath -w, even if the result may be somewhat unexpected in some 
border cases (which I haven't seen yet).

--
Thomas

--
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

Re: [ANNOUNCEMENT] Updated: gmp-6.1.2-1

[Yaakov Selkowitz]

On 2017-02-08 15:17, Denis Excoffier wrote:

Thank you for libgmp-6.1.2-1 that supersedes 6.1.1-1.

I noticed that libgmp.la is no longer present in the distribution (x86).

Is it okay?


Yes, .la files are generally going away.

--
Yaakov

--
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

Re: [ANNOUNCEMENT] Updated: gmp-6.1.2-1

[Denis Excoffier]

> Le 21 janv. 2017 à 20:19, Achim Gratz wrote:
> 
> 
> GNU Multiple Precision Arithmetic Library
> =
> 
> GMP is a free library for arbitrary precision arithmetic, operating on
> signed integers, rational numbers, and floating point numbers. There is
> no practical limit to the precision except the ones implied by the
> available memory in the machine GMP runs on. GMP has a rich set of
> functions, and the functions have a regular interface.
> 
> --8<---cut here---start->8---
> Changes in GMP 6.1.2
> (...)
> 
Hello,

Thank you for libgmp-6.1.2-1 that supersedes 6.1.1-1.

I noticed that libgmp.la is no longer present in the distribution (x86).

Is it okay?

Regards,

Denis Excoffier.


--
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

Re: perl-DateTime et.al.

[Achim Gratz]

Yaakov Selkowitz writes:
> On 2017-02-04 10:24, Achim Gratz wrote:
>> the versions of these in Cygwin get really long in the tooth and there
>> are several packages out there that have started to require the newer
>> versions available.  Could you please either update them or give me
>> co-maintainership so I can keep them updated during the regular
>> maintenance of all the other Perl distributions?  Thanks.
>
> I have given you joint maintainership of most of the Perl packages.

Could you please obsolete perl-HTML-Format (has been renamed
perl-HTML-Formatter) before I start updating?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [ANNOUNCEMENT] Updated: mintty 2.7.4

[Achim Gratz]

Thomas Wolff writes:
> Further comments welcome, and it's Achim's turn to provide further
> diagnostics input as requested in another mail. It could also be that
> screen or tmux simply make invalid assumptions about the setting of
> Wraparound modes.

That will take a while.  I'll have to set up something at home
specifically with the goal of reproducing the error.  At the moment it
looks like some sort of race between decisions made at different levels
of the stack mintty / tmux / mosh / screen since so far I've not been
able to reproduce if I take out one of these.

Are earlier versions of mintty, specifically the last versions of the
2.6 series, still available somewhere?  I'm almost certain that these
sort of things didn't happen before October or November last year.  Of
course it might have been another update of the other programs involved
as well.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
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

[ANNOUNCEMENT] fish 2.5.0-1

[Andrew Schulman]

fish 2.5.0-1 is now available in Cygwin.  This is a new upstream release,
with lots of fixes and improvements. See
https://fishshell.com/release_notes.html for the list.

fish is the friendly interactive shell. It's a Unix shell that focuses on
interactive use, discoverability, and user friendliness. The design goal of
fish is to give the user a rich set of powerful features in a way that is
easy to discover, remember, and use.

Home page: http://fishshell.com

Andrew E. Schulman


***


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com_at_cygwin.com

--
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

fish 2.5.0-1

[Andrew Schulman]

fish 2.5.0-1 is now available in Cygwin.  This is a new upstream release,
with lots of fixes and improvements. See
https://fishshell.com/release_notes.html for the list.

fish is the friendly interactive shell. It's a Unix shell that focuses on
interactive use, discoverability, and user friendliness. The design goal of
fish is to give the user a rich set of powerful features in a way that is
easy to discover, remember, and use.

Home page: http://fishshell.com

Andrew E. Schulman


***


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com_at_cygwin.com

Re: Segmentation Faults

[Marco Atzeri]

On 08/02/2017 18:13, Ian Lambert via cygwin wrote:

FWIW, since doing the updates late last month, many programs are seg faulting 
for me, including XWin, wget, curl, ssh, procps, top, gawk...

mintty, bash, vi, cd, and ls still work, so all is not lost, but I'm certainly 
not able to use cygwin as much as before,
and recovery is more difficult because of previously reported proxy issues with 
setup.
procps and top worked after reverting to old versions for "required" packages,
but I haven't been able to get wget to work, and apt-cyg is dead without gawk 
or wget. :(

This is 64 bit on Windos 7 "professional."


Below is excerpt from the end of a strace of wget http://www.yahoo.com/

Is "windows error 2" easy to fix? :)


Any bloda running around ?

I will bet on some other program interfering on cygwin
program execution or dll loading.

As example, recently strace is segfaulting on my W7 64 bit,
and I am almost sure Symantec is the guilty guy.

Check also if all the DLL needed by wget, curl, ssh, procps, top, gawk
are still there. I saw case where the Antivirus removed the dll's
without big notice.

Regards
Marco









--
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

Segmentation Faults

[Ian Lambert via cygwin]

FWIW, since doing the updates late last month, many programs are seg faulting 
for me, including XWin, wget, curl, ssh, procps, top, gawk...

mintty, bash, vi, cd, and ls still work, so all is not lost, but I'm certainly 
not able to use cygwin as much as before,
and recovery is more difficult because of previously reported proxy issues with 
setup.
procps and top worked after reverting to old versions for "required" packages,
but I haven't been able to get wget to work, and apt-cyg is dead without gawk 
or wget. :(

This is 64 bit on Windos 7 "professional."


Below is excerpt from the end of a strace of wget http://www.yahoo.com/

Is "windows error 2" easy to fix? :)


   21  258792 [main] wget 8408 fhandler_base::fstat_helper: 0 = fstat 
(\??\E:\cygwin64-2\dev, 0x1802E5A20) st_size=0, st_mode=040755, 
st_ino=32687320224st_atim=55FF8ED0.0 st_ctim=56003CF2.0 st_mtim=5600
3CF2.0 st_birthtim=56003CF0.1E65FB80
   22  258814 [main] wget 8408 stat_worker: 0 = 
(\??\E:\cygwin64-2\dev,0x1802E5A20)
   29  258843 [main] wget 8408 fstat64: 0 = fstat(3, 0xC920)
   26  258869 [main] wget 8408 getrusage: 0 = getrusage(0, 0xC9F0)
   17  258886 [main] wget 8408 getpid: 8408 = getpid()
   16  258902 [main] wget 8408 read: read(3, 0xC970, 32) blocking
--- Process 8408 loaded C:\Windows\System32\cryptbase.dll at 07fefcfe
 9169  268071 [main] wget 8408 read: 32 = read(3, 0xC970, 32)
 1572  269643 [main] wget 8408 read: read(3, 0xC970, 32) blocking
   86  269729 [main] wget 8408 read: 32 = read(3, 0xC970, 32)
   55  269784 [main] wget 8408 read: read(3, 0xC960, 8) blocking
   73  269857 [main] wget 8408 read: 8 = read(3, 0xC960, 8)
   63  269920 [main] wget 8408 getpid: 8408 = getpid()
--- Process 8408, exception c005 at 0003e8448020
  809  270729 [main] wget 8408 exception::handle: In cygwin_except_handler 
exception 0xC005 at 0x3E8448020 sp 0xCB68
   22  270751 [main] wget 8408 exception::handle: In cygwin_except_handler 
signal 11 at 0x3E8448020
   20  270771 [main] wget 8408 _cygtls::inside_kernel: pc 0x3E8448020, h 
0x3E842, inside_kernel 0
   21  270792 [main] wget 8408 normalize_posix_path: src /dev/kmsg
   16  270808 [main] wget 8408 normalize_posix_path: /dev/kmsg = 
normalize_posix_path (/dev/kmsg)
   16  270824 [main] wget 8408 mount_info::conv_to_win32_path: 
conv_to_win32_path (/dev/kmsg)
   16  270840 [main] wget 8408 mount_info::conv_to_win32_path: src_path 
/dev/kmsg, dst \Device\MailSlot\cygwin\dev\kmsg, flags 0x2, rc 0
   28  270868 [main] wget 8408 build_fh_pc: fh 0x1803171E0, dev 0001000B
   25  270893 [main] wget 8408 seterrno_from_nt_status: 
/home/corinna/src/cygwin/cygwin-2.7.0/cygwin-2.7.0-0.1.x86_64/src/newlib-cygwin/winsup/cygwin/fhandler_mailslot.cc:132
 status 0xC034 -> windows error 2
   20  270913 [main] wget 8408 geterrno_from_win_error: windows error 2 == 
errno 2
   17  270930 [main] wget 8408 sig_send: sendsig 0x98, pid 8408, signal 11, 
its_me 1
   19  270949 [main] wget 8408 sig_send: wakeup 0x258
   19  270968 [main] wget 8408 sig_send: Waiting for pack.wakeup 0x258
   19  270987 [sig] wget 8408 sigpacket::process: signal 11 processing
   24  271011 [sig] wget 8408 sigpacket::process: signal 11, signal handler 
0x18005CD10
   16  271027 [sig] wget 8408 sigpacket::setup_handler: controlled interrupt. 
stackptr 0xE458, stack 0xE458, stackptr[-1] 0xE458
   19  271046 [sig] wget 8408 proc_subproc: args: 5, 1
   15  271061 [sig] wget 8408 proc_subproc: clear waiting threads
   14  271075 [sig] wget 8408 proc_subproc: finished clearing
   14  271089 [sig] wget 8408 proc_subproc: returning 1
   14  271103 [sig] wget 8408 _cygtls::interrupt_setup: armed signal_arrived 
0x15C, signal 11
   16  271119 [sig] wget 8408 sigpacket::setup_handler: signal 11 delivered
   15  271134 [sig] wget 8408 sigpacket::process: returning 1
   14  271148 [sig] wget 8408 wait_sig: signalling pack.wakeup 0x258
   18  271166 [main] wget 8408 set_process_mask_delta: oldmask 0, newmask 0, 
deltamask 0
   27  271193 [main] wget 8408 signal_exit: exiting due to signal 11
 1953  273146 [main] wget 8408 cygwin_exception::open_stackdumpfile: Dumping 
stack trace to wget.exe.stackdump
155873  429019 [main] wget 8408 signal_exit: about to call do_exit (8B)
   74  429093 [main] wget 8408 do_exit: do_exit (139), exit_state 2
   37  429130 [main] wget 8408 void: 0x0 = signal (20, 0x1)
   32  429162 [main] wget 8408 void: 0x0 = signal (1, 0x1)
   27  429189 [main] wget 8408 void: 0x0 = signal (2, 0x1)
   51  429240 [main] wget 8408 void: 0x0 = signal (3, 0x1)
   34  429274 [main] wget 8408 fhandler_base::close_with_arch: line 1120:  
/dev/pty0<0x180316090> usecount + -1 = 2
   31  429305 [main] wget 8408 fhandler_base::close_with_arch: not closing 
archetype
   54  429359 [main] wget 8408 fhandler_base::close: closing '' handle 0x278

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: 

Re: cygpath -w converts relative paths to absolute windows paths

[Andrey Repin]

Greetings, Thomas Wolff!

> Am 07.02.2017 um 16:30 schrieb Andrey Repin:
>> Greetings, Roger Qiu!
>>
>>> I've found that `cygpath --windows '../` will give back an absolute windows 
>>> path.
>>> ...
>> ".." is a special path, that can't be safely converted.
> How is the special meaning of ".." so much different in Windows than in 
> Cygwin/Linux/POSIX that it could not be mapped?
> Things like dir .., cd .., type ..\sub\file all work comparably.

Comparable? May be. Predictable?
https://bugs.php.net/bug.php?id=73797


-- 
With best regards,
Andrey Repin
Wednesday, February 8, 2017 13:53:10

Sorry for my terrible english...


--
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