Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.1-1, libreadline-devel-7.0.1-1, bash-4.4.5-1

2017-01-12 Thread Steven Penny 
On Tue, 3 Jan 2017 10:34:01, "Eric Blake (cygwin)" wrote:
> The releases of readline 7.0.1-1 and bash 4.4.5-1, which have been
> experimental for a few weeks, have now been promoted to current.

Note that new version of libreadline7 breaks interactive non ASCII input. Please
see:

http://cygwin.com/ml/cygwin/2017-01/msg00066.html

downgrading to the following versions fixes the problem:

- libreadline7-6.3.8
- bash-4.3.48


--
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: Hangs on connect to UNIX socket being listened on in the same process (was: Cygwin hanging in pselect)

2017-01-12 Thread Michael Enright 
On Thu, Jan 12, 2017 at 2:13 PM, Corinna Vinschen
 wrote:
> Step 3:
>
>   If we did it really intelligent, maybe we finally also have a method
>   to implement descriptor passing.  Finally.  After all these years.
>
> And maybe, we should not actually use the socket itself to exchange
> the information but rather create some kind of side-channle for that.
>
> Especially in terms of step 3, I'm mulling over this for years now
> and always something else got in the way and had to be done first.
>
>

I made a program that needed to pass windows HANDLEs between processes
and so that receiving process could access the shared memory
represented by the HANDLEs. I was emulating facilities many programs
implement using send_msg, but I was using Windows (named?) pipes. It
felt a lot like what you need for send_msg, and it required newer
Windows APIs. So by doing the crazy thing of completely rewriting your
AF_UNIX sockets you could "easily" add descriptor passing.

--
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: Hangs on connect to UNIX socket being listened on in the same process (was: Cygwin hanging in pselect)

2017-01-12 Thread Corinna Vinschen 
On Jan 12 11:59, Erik Bray wrote:
> On Mon, Jan 9, 2017 at 6:16 PM, Corinna Vinschen wrote:
> > Right.  A better solution for the problem would be nice.  Ultimately
> > we want to check if the other side of the socket is actually a Cygwin
> > process which knows the secret, not a stray native Windows process
> > which accidentally hopped on the bandwagon, and we want to exchange
> > the credentials so a subsequent SO_PEERCRED call returns correct values.
> 
> Ah, okay. I found the original thread you mentioned, and I see that
> you sort of discussed some possibilities but nothing was quite
> satisfactory at the time, and it was dropped--you mentioned some idea
> about exchanging information via pipes, but that was a bit complicated
> and half-baked.
> 
> Christian described a scheme in that thread which at least seemed like
> a way out of the connect hanging problem, and also improved the
> security (I think) by having separate server and client secrets, so
> that a malicious server could not gain the socket secret from the
> client.  But he also worried:
> 
> > The only drawback which remains is that the client performs the send()
> > before first recv() unconditionally. It will realize the bad server secret
> > lately on first recv().
> 
> Though you wrote:
> 
> > Yeah, but it might be better than nothing and if it avoids the hangs,
> > even better.
> 
> Which is sort of how I feel, though I do appreciate the security
> implication.

I'm not sure there actually are security implications.  AF_LOCAL sockets
are local only, no network access.  And every Cygwin process knowing the
name of the socket file and having sufficient permisson to read the file
can connect.  And even a non-Cygwin process written by someone who knows
how Cygwin AF_LOCAL sockets work.  It's open source after all.

What this method mainly solves is to make reasonably sure that the peers
are actually Cygwin processes on both sides which know that this is an
AF_INET socket emulating an AF_LOCAL socket.  Plus SO_PEERCRED
emulation, but that's another problem just attached to the original
handshake.

Maybe we need to take a step back and just consider for a while what we
want:

Step 1:

  Make sure with whatever method that the process on the other side is
  actually a Cygwin process opening this socket as an AF_LOCAL socket.

Step 2:

  Exchange SO_PEERCRED information.

Step 3:

  If we did it really intelligent, maybe we finally also have a method
  to implement descriptor passing.  Finally.  After all these years.

And maybe, we should not actually use the socket itself to exchange
the information but rather create some kind of side-channle for that.

Especially in terms of step 3, I'm mulling over this for years now
and always something else got in the way and had to be done first.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: rename() cannot replace the file which is opened with writable access

2017-01-12 Thread Corinna Vinschen 
On Jan 12 09:07, Masamichi Hosoda wrote:
> Hello,
> 
> I've found that rename() cannot replace the file
> which is opened with writable access on Cygwin.
> On Linux, it works.
> 
> If I understand correctly, it should work under POSIX.
> 
> Here's sample code for reproduce.

Thanks for the testcase.  I applied a patch(*) and will upload a new
developer snapshot for testing to https://cygwin.com/snapshots/
at some point tomorrow.


Corinna

(*) https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=6ed4753

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

[newlib-cygwin] Add release message for commit 6ed4753

2017-01-12 Thread Corinna Vinschen 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=677ffdc2474aa0b5ae9e8b1e4a3f20046e0f1232

commit 677ffdc2474aa0b5ae9e8b1e4a3f20046e0f1232
Author: Corinna Vinschen 
Date:   Thu Jan 12 22:46:21 2017 +0100

Add release message for commit 6ed4753

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/release/2.7.0 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/release/2.7.0 b/winsup/cygwin/release/2.7.0
index 5f84953..bbcab99 100644
--- a/winsup/cygwin/release/2.7.0
+++ b/winsup/cygwin/release/2.7.0
@@ -13,4 +13,5 @@ What changed:
 Bug Fixes
 -
 
-
+- Fix rename(2) fail with EACCES if newfile is in use.
+  Addresses: https://cygwin.com/ml/cygwin/2017-01/msg00108.html

[ANNOUNCEMENT] Updated: shutdown 2.0-1

2017-01-12 Thread Frank Fesevur 
Hi,

I've just updated the version of shutdown to v2.0-1 and it can be
found at a server near you.


FULL CHANGELOG (since shutdown-1.10-1)
==

* Added --install to install Windows Updates during shutdown/reboot.

  The InitiateShutdown() Windows API call is used for this. This function is
  only available from Windows 6.0 (aka Vista or Server 2008) or higher.
  To assure backwards compatibility with WinXP and Server 2003,
  InitiateShutdown() is loaded dynamically at runtime. Since Cygwin 2.6
  support for Windows XP and Server 2003 has been dropped, so this backward
  compatibility will be removed in a future release.

* Added --hybrid to shutdown in hybrid mode. Hybrid is the default shutdown
  method with shutting down with the UI of Windows 8.x and higher.

* The default shutdown messages will give more information on what is about
  to happen.

* User can supply his own shutdown message on the command line.

Enjoy!

Regards,
Frank

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

Updated: shutdown 2.0-1

2017-01-12 Thread Frank Fesevur 
Hi,

I've just updated the version of shutdown to v2.0-1 and it can be
found at a server near you.


FULL CHANGELOG (since shutdown-1.10-1)
==

* Added --install to install Windows Updates during shutdown/reboot.

  The InitiateShutdown() Windows API call is used for this. This function is
  only available from Windows 6.0 (aka Vista or Server 2008) or higher.
  To assure backwards compatibility with WinXP and Server 2003,
  InitiateShutdown() is loaded dynamically at runtime. Since Cygwin 2.6
  support for Windows XP and Server 2003 has been dropped, so this backward
  compatibility will be removed in a future release.

* Added --hybrid to shutdown in hybrid mode. Hybrid is the default shutdown
  method with shutting down with the UI of Windows 8.x and higher.

* The default shutdown messages will give more information on what is about
  to happen.

* User can supply his own shutdown message on the command line.

Enjoy!

Regards,
Frank

Re: Updated: {jasper/libjasper1/libjasper-devel}-1.900.22-1: JPEG-2000 codec library

2017-01-12 Thread Yaakov Selkowitz 

On 2017-01-03 08:32, Dr. Volker Zell wrote:

New versions of 'jasper/libjasper1/libjasper-devel' have been uploaded to a 
server near you.

 o Build for cygwin 2.6.1 with gcc-5.4.0
 o Update to latest version before ABI bump


Not really; the fix therein for CVE-2015-5203 broke ABI on 64-bit 
systems by changing the size of an existing member of a public struct 
(int to size_t), just that they neglected to bump the ABI version until 
afterwards:


https://github.com/mdadams/jasper/issues/84

For compatibility with packages currently linked with libjasper1, this 
needs to be reverted in part.  Here is what Fedora is currently shipping 
on stable branches:


http://pkgs.fedoraproject.org/cgit/rpms/jasper.git/tree/?h=f25

Then, we could update to 1.900.29, or even 2.0.10 -- which should 
provide libjasper4 -- against which all jasper-dependent packages would 
then have to be rebuilt.


--
Yaakov

Re: rename() cannot replace the file which is opened with writable access

2017-01-12 Thread L. A. Walsh 

Masamichi Hosoda wrote:

Hello,

I've found that rename() cannot replace the file
which is opened with writable access on Cygwin.
On Linux, it works.

If I understand correctly, it should work under POSIX.

Here's sample code for reproduce.

---

#define OLDPATH "oldpath"
#define NEWPATH "newpath"

int main () {
  int fd;
  struct flock fl;
  char buff[] = "test";
  fd = open (OLDPATH, O_CREAT | O_RDWR | O_TRUNC, 0666);
  close (fd);
  fd = open (NEWPATH, O_CREAT | O_RDWR | O_TRUNC, 0666);
  if (rename (OLDPATH, NEWPATH) < 0)  perror ("rename");
  


   What are you trying to do by renaming the oldfile
over the top of a still-open-for-write, "newfile".

   Why rename over the top of another file?  What are you trying
to do?  Maybe there is a better way to do it?  ;-). 


--
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: hang on 'cat /proc/mounts' when one of the network drives is on a 'down' system

2017-01-12 Thread Corinna Vinschen 
On Jan 12 11:47, cyg Simple wrote:
> On 1/12/2017 10:00 AM, Corinna Vinschen wrote:
> > On Jan 11 19:13, L. A. Walsh wrote:
> >> Corinna Vinschen wrote:
> >>> I know why this happens but I don't see an easy way around that.
> >>> Basically the problem is that Cygwin has no control over the OS mount
> >>> points (i. e., drive letter mapping and volume ireparse points).  Given
> >>> that, apart from C: maybe, the drive letter mapping can change any time,
> >>> Cygwin doesn't cache the information but requests it every time it needs
> >>> it.  This includes information required in /proc/mounts, here basically
> >>> the FS type.  This in turn requires to open a handle to the FS, which
> >>> may result in the observed hang.
> >> 
> >>Thanks for the explanation.  Looking at my ".bashrc",
> >> I can't figure out why needed this so I can comment it out.
> >> However, as an "aside", I'm not sure why my workaround
> >> didn't work...though I might guess.
> >>
> >> I tried using 'timeout' from 'coreutils-8.23-4' like:
> >> readarray -t proc_mounts< <(timeout -k 2 1 cat /proc/mounts)
> >>
> >> I had hoped that w/cat hanging, timeout waits 1 second (2nd
> >> number), and if no response after the #secs after -k (2)
> >> then it's suppose to try to kill it.
> >>
> >> I'm guessing that since it's a cygwin signal, it is probably
> >> waiting for Win to return to cygwin land so cygwin can
> >> process the signal -- but since it's off in la la land,
> >> cygwin doesn't get a chance to clean up.
> > 
> > Exactly.  The hanging call is just some NtOpenFile call on the
> > filesystem.  The timeout is an unfortunate effect of accessing
> > a remote drive.  One problem here is that Cygwin doesn't support
> > interrupting of synchroneous Windows I/O calls from the signal
> > handler.  That's something I'm planning to do at one point, but
> > don't hold your breath.
> 
> You may be able to configure the timeout response on the device to
> reduce the wait.

How so?  If it requires changing the registry it's not something
Cygwin can do on the fly without admin consent.  Only if we can
define a timeout on the application level we could use it.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: [ANNOUNCEMENT] Updated: Cygwin 2.6.1-1

2017-01-12 Thread David Macek 
On 10. 1. 2017 1:39, Steven Penny wrote:
> On Sun, 18 Dec 2016 09:41:29, Corinna Vinschen wrote:
>> - Fix regression in console charset handling
>>   Addresses: https://cygwin.com/ml/cygwin/2016-10/msg0.html
> 
> It looks like fixing this may have caused another issue. Example test:
> 
> With cmd.exe, you can type Alt 234 and it produces
> GREEK CAPITAL LETTER OMEGA U+03A9. However with Cygwin via Cygwin.bat it 
> yields
> nothing. Non ASCII characters can be read from scripts, but they cannot be
> entered interactively.
> 
> They cannot be pasted either; pasting some words will remove all non ASCII
> characters.
> 
> I believe this to be a recent issue, if memory serves this did work before, 
> and
> should given that cmd.exe handles it fine.

My experience:

conhostv2+cmd: Shift+Ins -> ŕ
conhostv2+cmd: Alt+234 -> ŕ

conhostv2+cygwin260+bash: Shift+Ins -> ŕ
conhostv2+cygwin260+bash: Alt+234 -> ŕ

conhostv2+cygwin261+bash: Shift+Ins -> ŕ
conhostv2+cygwin261+bash: Alt+234 -> 
(i.e. nothing)
conhostv2+cygwin261+bash: Alt+5 -> [G
(if there's nothing written yet on the input line, Alt+5 also causes what seems 
to be ~10-second delay in input processing)

mintty+cygwin261+bash: Shift+Ins -> ŕ
mintty+cygwin261+bash: Alt+234 -> ê


Versions and settings:

$ uname -a
CYGWIN_NT-10.0 mew 2.6.0(0.304/5/3) 2016-08-31 14:32 x86_64 Cygwin
$ uname -a
CYGWIN_NT-10.0 mew 2.6.1(0.305/5/3) 2016-12-16 11:55 x86_64 Cygwin

$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=

$ /proc/cygdrive/c/Windows/System32/chcp.com
Active code page: 65001

Using the font Consolas.


-- 
David Macek



smime.p7s
Description: S/MIME Cryptographic Signature

Re: borgbackup test fail on cygwin (only) - cygwin pipe issues?

2017-01-12 Thread Thomas Waldmann 
>> https://github.com/borgbackup/borg/issues/1268
> 
> Are your pipe handles in open in binary mode or text mode?  You should
> always ensure they are in binary mode.

That was my first idea also.

https://github.com/borgbackup/borg/blob/1.0.9/borg/remote.py#L188 this
is the place where the ssh subprocess is forked and the pipes are set up.

There is nothing special about binary mode there, but as mentioned in
that ticket, I just tried it out to send binary data over such pipes and
it worked:

https://github.com/borgbackup/borg/issues/1268#issuecomment-239923192

(that \n should get modified to \r\n if in text mode, but it got through
"as is")


-- 

GPG ID: 9F88FB52FAF7B393
GPG FP: 6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393


--
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: borgbackup test fail on cygwin (only) - cygwin pipe issues?

2017-01-12 Thread cyg Simple 
On 1/10/2017 10:47 PM, Thomas Waldmann wrote:
> Hi,
> 
> borgbackup uses a RPC protocol via a ssh pipe to implement client/server
> communication.
> 
> borg client --pipe-- ssh --tcp-- sshd --pipe-- borg serve
> 
> This works very reliable, we have tests running on linux, freebsd,
> netbsd, openbsd, OS X. It even works on win10 linux subsystem.
> 
> But on Cygwin, only the local tests work, but the remote tests (which
> need the pictured ssh pipe) fail or hang.
> 
> When trying to find out what's going wrong, I noticed corrupted data
> coming over the pipe.
> 
> I've found some other pipe issues on the cygwin mailing list, maybe this
> is related?
> 
> Our issue about this:
> 
> https://github.com/borgbackup/borg/issues/1268
> 

Are your pipe handles in open in binary mode or text mode?  You should
always ensure they are in binary mode.

-- 
cyg Simple

--
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: hang on 'cat /proc/mounts' when one of the network drives is on a 'down' system

2017-01-12 Thread cyg Simple 
On 1/12/2017 10:00 AM, Corinna Vinschen wrote:
> On Jan 11 19:13, L. A. Walsh wrote:
>> Corinna Vinschen wrote:
>>> I know why this happens but I don't see an easy way around that.
>>> Basically the problem is that Cygwin has no control over the OS mount
>>> points (i. e., drive letter mapping and volume ireparse points).  Given
>>> that, apart from C: maybe, the drive letter mapping can change any time,
>>> Cygwin doesn't cache the information but requests it every time it needs
>>> it.  This includes information required in /proc/mounts, here basically
>>> the FS type.  This in turn requires to open a handle to the FS, which
>>> may result in the observed hang.
>> 
>>Thanks for the explanation.  Looking at my ".bashrc",
>> I can't figure out why needed this so I can comment it out.
>> However, as an "aside", I'm not sure why my workaround
>> didn't work...though I might guess.
>>
>> I tried using 'timeout' from 'coreutils-8.23-4' like:
>> readarray -t proc_mounts< <(timeout -k 2 1 cat /proc/mounts)
>>
>> I had hoped that w/cat hanging, timeout waits 1 second (2nd
>> number), and if no response after the #secs after -k (2)
>> then it's suppose to try to kill it.
>>
>> I'm guessing that since it's a cygwin signal, it is probably
>> waiting for Win to return to cygwin land so cygwin can
>> process the signal -- but since it's off in la la land,
>> cygwin doesn't get a chance to clean up.
> 
> Exactly.  The hanging call is just some NtOpenFile call on the
> filesystem.  The timeout is an unfortunate effect of accessing
> a remote drive.  One problem here is that Cygwin doesn't support
> interrupting of synchroneous Windows I/O calls from the signal
> handler.  That's something I'm planning to do at one point, but
> don't hold your breath.

You may be able to configure the timeout response on the device to
reduce the wait.  Beyond that we are at the mercy of Windows.

-- 
cyg Simple

--
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: rename() cannot replace the file which is opened with writable access

2017-01-12 Thread cyg Simple 
On 1/12/2017 10:36 AM, Corinna Vinschen wrote:
> On Jan 12 15:30, Nellis, Kenneth (Conduent) wrote:
>> From: Masamichi Hosoda
>>> If I understand correctly,
>>> POSIX behavior should be able to replace the writable opened file by
>>> rename().
>>> But, It does not work on my Cygwin environment.
>>>
>>> Is it no problem if Cygwin's behavior is different from POSIX behavior?
>>> If so, we need different application handling for Cygwin and POSIX.
>>
>> I thought it would be informative to respond by referring the OP
>> to a section of the Cygwin User's Guide or FAQ that mentioned the
>> limitations of Cygwin, but I could not find it.
> 
> Needs debugging.  Off the top of my head I have no clue why this
> doesn't work.  I'm just not near any Windows machine ATM...

Possibly BLODA.  In the sample code provided, the rename is trying to
rename the open file to an existing filename that was recently (within
microseconds) created.

-- 
cyg Simple

--
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: lapack-3.7.0-1

2017-01-12 Thread Ian Lambert via cygwin 

On Thu, 1/12/17, Marco Atzeri  wrote:

 Subject: Re: [ANNOUNCEMENT] Updated: lapack-3.7.0-1
 To: "Ian Lambert" , cygwin@cygwin.com
 Date: Thursday, January 12, 2017, 6:58 AM
 
 On 11/01/2017 21:29, Ian
 Lambert wrote:
 > On January 11, 2017
 3:41:42 AM EST, Marco Atzeri  wrote:
 >> To: cygwin-annou...@cygwin.com
 >> Subject: Updated: lapack-3.7.0-1
 >>
 >> New
 versions  lapack-3.7.0-1 of
 >>
 >> lapack (source)
 >> liblapack0
 >>
 liblapack-devel
 >> liblapack-doc
 >>
 >> are available
 in the Cygwin distribution, 32 and 64 bit :
 >>
 >
 > Is anyone else having problems with
 ...-Doc hanging with a pop-up, "unable to extract
 /use/share/man/man3/zhbev.3.gz. The file is in use or some
 other error occurred. Please stop all cygwin processes and
 select retry or select continue to go on anyway (the file
 will be updated after a reboot)."
 >
 ?
 >
 > Then when I hit
 continue, setup hangs there until hitting cancel. I've
 tried a few times, uninstall and reinstall.
 >
 
 The files uploaded seem fine.
 Can you check the one you downloaded with
 
 tar -tf
 liblapack-doc-3.7.0-1.tar.xz
 
 If damaged, remove it and try to download it
 again
 
= = = = =
I've removed it and downloaded again already.
Everything seems fine, but the above behavior repeats, for me.
Below is some more info'.

$ tar -tf liblapack-doc-3.7.0-1.tar.xz | grep -i zhbev.3
usr/share/man/man3/LAPACKE_zhbev.3.gz
usr/share/man/man3/LAPACK_zhbev.3.gz
usr/share/man/man3/zhbev.3.gz

$ tar -xvJf liblapack-doc-3.7.0-1.tar.xz usr/share/man/man3/zhbev.3.gz
usr/share/man/man3/zhbev.3.gz

[install dir...]/x86_64/release/lapack/liblapack-doc/usr/share/man/man3
$ ls -ls
... 59 Jan 10 17:14 zhbev.3.gz

/usr/share/man/man3
$ ls -ls zhbev.3.gz
ls: cannot access 'zhbev.3.gz': No such file or directory

$ ls -ls *zhbev.3*
... 57 Jan 10 16:59 LAPACKE_zhbev.3.gz
... 56 Jan 10 17:02 LAPACK_zhbev.3.gz




--
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: rename() cannot replace the file which is opened with writable access

2017-01-12 Thread Corinna Vinschen 
On Jan 12 15:30, Nellis, Kenneth (Conduent) wrote:
> From: Masamichi Hosoda
> > If I understand correctly,
> > POSIX behavior should be able to replace the writable opened file by
> > rename().
> > But, It does not work on my Cygwin environment.
> > 
> > Is it no problem if Cygwin's behavior is different from POSIX behavior?
> > If so, we need different application handling for Cygwin and POSIX.
> 
> I thought it would be informative to respond by referring the OP
> to a section of the Cygwin User's Guide or FAQ that mentioned the
> limitations of Cygwin, but I could not find it.

Needs debugging.  Off the top of my head I have no clue why this
doesn't work.  I'm just not near any Windows machine ATM...


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

RE: rename() cannot replace the file which is opened with writable access

2017-01-12 Thread Nellis, Kenneth (Conduent) 
From: Masamichi Hosoda
> If I understand correctly,
> POSIX behavior should be able to replace the writable opened file by
> rename().
> But, It does not work on my Cygwin environment.
> 
> Is it no problem if Cygwin's behavior is different from POSIX behavior?
> If so, we need different application handling for Cygwin and POSIX.

I thought it would be informative to respond by referring the OP
to a section of the Cygwin User's Guide or FAQ that mentioned the
limitations of Cygwin, but I could not find it.

--Ken Nellis

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

Customizing bash user guide out-of-date

2017-01-12 Thread Nellis, Kenneth (Conduent) 
Chapter 2 of the Cygwin User's Guide [1] has a section called "Customizing 
bash" [2]. 
This section starts off: 

To set up bash so that cut and paste work properly, click on the 
"Properties" 
button of the window, then on the "Misc" tab.

Two problems:
(1) This statement doesn't apply to folks who are running the default terminal 
emulation program, mintty.
(2) If folks are invoking bash directly from the Windows console, the cmd.exe 
tab 
is named "Options", at least for Windows 7, which I am running. Perhaps it was 
named
"Misc" once upon a time.

Since the statement doesn't apply to the default (mintty) installation, perhaps 
the 
paragraph should simply be deleted. Alternatively, I suggest replacing the 
sentence 
with the following:

To set up bash so that cut and paste work properly while running the 
Windows 
console program, cmd.exe, click on the "Properties" button of the 
window, then
on the "Options" tab.

[1] https://cygwin.com/cygwin-ug-net/cygwin-ug-net.html
[2] https://cygwin.com/cygwin-ug-net/setup-files.html

--Ken Nellis

--
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: hang on 'cat /proc/mounts' when one of the network drives is on a 'down' system

2017-01-12 Thread Corinna Vinschen 
On Jan 11 19:13, L. A. Walsh wrote:
> Corinna Vinschen wrote:
> > I know why this happens but I don't see an easy way around that.
> > Basically the problem is that Cygwin has no control over the OS mount
> > points (i. e., drive letter mapping and volume ireparse points).  Given
> > that, apart from C: maybe, the drive letter mapping can change any time,
> > Cygwin doesn't cache the information but requests it every time it needs
> > it.  This includes information required in /proc/mounts, here basically
> > the FS type.  This in turn requires to open a handle to the FS, which
> > may result in the observed hang.
> 
>Thanks for the explanation.  Looking at my ".bashrc",
> I can't figure out why needed this so I can comment it out.
> However, as an "aside", I'm not sure why my workaround
> didn't work...though I might guess.
> 
> I tried using 'timeout' from 'coreutils-8.23-4' like:
> readarray -t proc_mounts< <(timeout -k 2 1 cat /proc/mounts)
> 
> I had hoped that w/cat hanging, timeout waits 1 second (2nd
> number), and if no response after the #secs after -k (2)
> then it's suppose to try to kill it.
> 
> I'm guessing that since it's a cygwin signal, it is probably
> waiting for Win to return to cygwin land so cygwin can
> process the signal -- but since it's off in la la land,
> cygwin doesn't get a chance to clean up.

Exactly.  The hanging call is just some NtOpenFile call on the
filesystem.  The timeout is an unfortunate effect of accessing
a remote drive.  One problem here is that Cygwin doesn't support
interrupting of synchroneous Windows I/O calls from the signal
handler.  That's something I'm planning to do at one point, but
don't hold your breath.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: rename() cannot replace the file which is opened with writable access

2017-01-12 Thread Masamichi Hosoda 
>> I've found that rename() cannot replace the file
>> which is opened with writable access on Cygwin.
>> On Linux, it works.
> 
> It is OS dependent behavior, and vary even on same OS.
> Windows may let you rename a file, or may not, depends on how exactly it is
> opened.

Thank you for your answer.

If I understand correctly,
POSIX behavior should be able to replace the writable opened file by rename().
But, It does not work on my Cygwin environment.

Is it no problem if Cygwin's behavior is different from POSIX behavior?
If so, we need different application handling for Cygwin and POSIX.

--
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: Cygwin 2.6.1-1

2017-01-12 Thread John Hein 
Steven Penny wrote at 16:39 -0800 on Jan  9, 2017:
 > On Sun, 18 Dec 2016 09:41:29, Corinna Vinschen wrote:
 > > - Fix regression in console charset handling
 > >   Addresses: https://cygwin.com/ml/cygwin/2016-10/msg0.html
 > 
 > It looks like fixing this may have caused another issue. Example test:
 > 
 > With cmd.exe, you can type Alt 234 and it produces
 > GREEK CAPITAL LETTER OMEGA U+03A9. However with Cygwin via Cygwin.bat it 
 > yields
 > nothing. Non ASCII characters can be read from scripts, but they cannot be
 > entered interactively.
 > 
 > They cannot be pasted either; pasting some words will remove all non ASCII
 > characters.
 > 
 > I believe this to be a recent issue, if memory serves this did work before, 
 > and
 > should given that cmd.exe handles it fine.

It behaves the same as you describe above (yields nothing) here
with cygwin 2.6.0-1 and bash 4.3.46-7 on windows 7/32.

But it works as expected (yields omega) if you run tcsh instead of
bash from the cmd.exe window dos prompt... or even if you run tcsh
from within the bash.

--
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] Updated: lilypond-2.19.54-1

2017-01-12 Thread Marco Atzeri 

Versions 2.19.54-1  of
lilypond
lilypond-doc

for cygwin are now available:

CHANGES
Last dev upstream release
http://www.lilypond.org/old-news.html

DESCRIPTION
LilyPond is a music engraving program, devoted to producing the
highest-quality sheet music possible. It brings the aesthetics of
traditionally engraved music to computer printouts.
LilyPond is free software and part of the GNU Project.

The HTML documentions was replaced with PDF one.
The HTML version is available online at:
http://www.lilypond.org/manuals.html

HOMEPAGE
http://www.lilypond.org/


Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) 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

Updated: lilypond-2.19.54-1

2017-01-12 Thread Marco Atzeri 

Versions 2.19.54-1  of
lilypond
lilypond-doc

for cygwin are now available:

CHANGES
Last dev upstream release
http://www.lilypond.org/old-news.html

DESCRIPTION
LilyPond is a music engraving program, devoted to producing the
highest-quality sheet music possible. It brings the aesthetics of
traditionally engraved music to computer printouts.
LilyPond is free software and part of the GNU Project.

The HTML documentions was replaced with PDF one.
The HTML version is available online at:
http://www.lilypond.org/manuals.html

HOMEPAGE
http://www.lilypond.org/


Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

Re: [ITP] mdp 1.0.9

2017-01-12 Thread Michael Göhler 
Thanks for the first review.

I’ve corrected the PREFIX and uploaded the files again.
May I ask for another review?



--
Hints:
--

mdp-1.0.9-1.hint
--
category: Utils
requires: cygwin libncursesw10 
sdesc: "A command-line based markdown presentation tool"
ldesc: "A ncurses-based command-line presentation tool, which makes
it easy to create slides using the popular markdown format."

mdp-debuginfo-1.0.9-1.hint
--
category: Debug
requires: cygwin-debuginfo
external-source: mdp
sdesc: "Debug info for mdp"
ldesc: "This package contains files necessary for debugging the
mdp package with gdb."



--
Packages:
--

x86_64:
--
http://raw.nixhub.de/cygwin/x86_64/mdp/mdp-1.0.9-1.tar.xz
http://raw.nixhub.de/cygwin/x86_64/mdp/mdp-1.0.9-1-src.tar.xz
http://raw.nixhub.de/cygwin/x86_64/mdp/mdp-1.0.9-1.hint
http://raw.nixhub.de/cygwin/x86_64/mdp/mdp-debuginfo/mdp-debuginfo-1.0.9-1.tar.xz
http://raw.nixhub.de/cygwin/x86_64/mdp/mdp-debuginfo/mdp-debuginfo-1.0.9-1.hint

x86:
--
http://raw.nixhub.de/cygwin/x86/mdp/mdp-1.0.9-1.tar.xz
http://raw.nixhub.de/cygwin/x86/mdp/mdp-1.0.9-1-src.tar.xz
http://raw.nixhub.de/cygwin/x86/mdp/mdp-1.0.9-1.hint
http://raw.nixhub.de/cygwin/x86/mdp/mdp-debuginfo/mdp-debuginfo-1.0.9-1.tar.xz
http://raw.nixhub.de/cygwin/x86/mdp/mdp-debuginfo/mdp-debuginfo-1.0.9-1.hint



> On 9 Jan 2017, at 18:26, Jon Turney  wrote:
> 
> On 30/12/2016 16:11, Michael Göhler wrote:
>> Hi,
>> 
>> i’ve packaged mdp and would like to become the package maintainer for it.
>> mdp is available at https://github.com/visit1985/mdp under GPLv3.
>> 
>> Currently it is included in:
>> * Arch Linux: https://aur.archlinux.org/packages/mdp-git/
>> * Debian: https://tracker.debian.org/pkg/mdp-src
>> * FreeBSD: http://www.freshports.org/misc/mdp
>> * OS-X: http://brewformulas.org/Mdp
>> * Slackware: http://slackbuilds.org/apps/mdp/
>> * Ubuntu: https://launchpad.net/ubuntu/+source/mdp-src
>> 
> 
> Thanks for this.
> 
> It seems that these packages install mdp.exe into /usr/local/bin/.
> per [1], this is not correct.
> 
> I guess you need to investigate supplying the correct value of PREFIX to the 
> Makefile.
> 
> Apart from that, looks good to me.
> 
> [1] https://cygwin.com/packaging-package-files.html#package_contents
> 
>

Awk print statement alters the argument variable's content

2017-01-12 Thread Lundberg Christer 
This program run with GNU awk 4.1.4 (currently installed with Cygwin):

  awk '
BEGIN { OFMT="%.8g"
buf = 1+0.1
buf = buf "a"
print "Length before print:", length(buf)
print buf " "
print buf
print buf " "
print "Length after print:", length(buf)
  }
  '

produces the following output on our system:

Length before print: 4
1.1a 
1.1
1.1 
Length after print: 3

so it appears that the "print buf" statement unexpectedly alters the content of 
buf.
With awk 4.1.3, we got the expected output

Length before print: 4
1.1a 
1.1a
1.1a 
Length after print: 4


--
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: Debugging MariaDB Severe Crash (mysqld daemon dies)

2017-01-12 Thread OwN-3m-All 
Can anyone help with this?  I'm pretty sure this is a bug with the
latest cygwin package for mariadb since the queries work fine in Linux
(older versions of MySQL / MariaDB).

Would be nice to be able to actually troubleshoot this further, but
without any good logs, I don't know where to go to next.

--
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: postgresql - Cannot initialize new Postgres database on Cygwin - Super User

2017-01-12 Thread Marco Atzeri 

On 11/01/2017 23:02, Chloe wrote:

When I try to initialize a new database, I get an error:

$ /usr/sbin/pg_ctl init
no data was returned by command ""/usr/sbin/initdb.exe" -V"
The program "initdb" is needed by pg_ctl but was not found in the
same directory as "/usr/sbin/pg_ctl".
Check your installation.

$ /usr/sbin/initdb.exe -V
initdb (PostgreSQL) 9.6.1

$ "/usr/sbin/initdb.exe" -V
initdb (PostgreSQL) 9.6.1

$ /usr/sbin/initdb.exe -D /usr/share/postgresql
no data was returned by command ""/usr/sbin/postgres.exe" -V"
The program "postgres" is needed by initdb but was not found in the
same directory as "/usr/sbin/initdb".
Check your installation.

$ /usr/sbin/postgres -V
postgres (PostgreSQL) 9.6.1

Cygwin 2.6.1, Postgres 9.6.1


http://superuser.com/questions/1166177/cannot-initialize-new-postgres-database-on-cygwin



Inizialization works for me

$ cygrunsrv -S cygserver

$ /usr/sbin/initdb -D /usr/local/pgsql/data
The files belonging to this database system will be owned by user "marco".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

creating directory /usr/local/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 30
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... sysv
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

pg_ctl -D /usr/local/pgsql/data -l logfile start

$ pg_ctl -D /usr/local/pgsql/data -l logfile start
server starting

$ psql -l
  List of databases
   Name| Owner | Encoding |   Collate   |Ctype| Access 
privileges

---+---+--+-+-+---
 postgres  | marco | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
 template0 | marco | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/marco 
 +

   |   |  | | | marco=CTc/marco
 template1 | marco | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/marco 
 +

   |   |  | | | marco=CTc/marco
(3 rows)


can you provide your cygcheck.out ?
https://www.cygwin.com/problems.html

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

Re: [ANNOUNCEMENT] Updated: lapack-3.7.0-1

2017-01-12 Thread Marco Atzeri 

On 11/01/2017 21:29, Ian Lambert wrote:

On January 11, 2017 3:41:42 AM EST, Marco Atzeri  wrote:

To: cygwin-annou...@cygwin.com
Subject: Updated: lapack-3.7.0-1

New versions  lapack-3.7.0-1 of

lapack (source)
liblapack0
liblapack-devel
liblapack-doc

are available in the Cygwin distribution, 32 and 64 bit :



Is anyone else having problems with ...-Doc hanging with a pop-up, "unable to 
extract /use/share/man/man3/zhbev.3.gz. The file is in use or some other error occurred. 
Please stop all cygwin processes and select retry or select continue to go on anyway (the 
file will be updated after a reboot)."
?

Then when I hit continue, setup hangs there until hitting cancel. I've tried a 
few times, uninstall and reinstall.




The files uploaded seem fine.
Can you check the one you downloaded with

tar -tf liblapack-doc-3.7.0-1.tar.xz

If damaged, remove it and try to download it again

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

Re: Hangs on connect to UNIX socket being listened on in the same process (was: Cygwin hanging in pselect)

2017-01-12 Thread Erik Bray 
On Mon, Jan 9, 2017 at 6:16 PM, Corinna Vinschen
 wrote:
> On Jan  9 16:46, Erik Bray wrote:
>> Hi Corinna,
>>
>> Thanks for the response.
>>
>> On Mon, Jan 9, 2017 at 3:13 PM, Corinna Vinschen wrote:
>> > Right.  It has to do with how connect/accept works on AF_LOCAL sockets.
>> > The handshake doesn't work well for situations like yours, where the
>> > same thread tries to connect and accept on the same socket.
>>
>> Actually I'm not entirely sure now that that's the issue, even
>> considering that this has come up before.  Or at the very least,
>> there's an additional issue.  I realized that when I tried separate
>> client/server processes, in the server I had put an accept() call at
>> the end so it would block there.  With the server waiting to accept a
>> connection it succeeded.  However, when I replaced the accept() with a
>> long sleep(), the client's connect() never returns.
>
> That's because connect infinitely waits for the accept to reply the
> second half of the handshake.
>
>> IIUC the handshake can't succeed until and unless the server accepts a
>> connection from the client.
>
> This is exactly the underlying problem.  And interesting enough, even
> though the handshake is in Cygwin since 2001, we never had a problem
> with this until Christian started porting postfix in 2014!
>
>> I almost wonder if the server side in this case
>> shouldn't start up a thread to accept the af_local handshake, but you
>> would know better.
>
> No, I don't.  We discussed this issue briefly back in 2014, but as
> you can see we don't have a solution for this border case yet.
>
> Starting a thread may or may not work, but there are a couple of
> use-cases to keep in mind (which I can't reproduce off the top of my head).
> The old postfix cygwin-apps thread from 2014 might give you some idea.
>
>> > This has been found a problem in porting postfix already and at the time
>> > we added a patch to circumvent the problem.  Before calling connect, add
>> > this:
>> >
>> >   setsockopt (sock_server, SOL_SOCKET, SO_PEERCRED, NULL, 0);
>> >   setsockopt (sock_client, SOL_SOCKET, SO_PEERCRED, NULL, 0);
>> >
>> > This is, of course, a hack.  The problem here is that server and client
>> > of a socket are independent of each other, and there's typically no
>> > way to know which process created the server side unless you already
>> > are connected.  Chicken/egg.
>>
>> I tried it and it worked, both in the single process and separate
>> process examples.  I see now--this sets
>> fhandler_socket::no_getpeerid=true, so it doesn't have to do the
>> handshake at all.
>
> Right.  A better solution for the problem would be nice.  Ultimately
> we want to check if the other side of the socket is actually a Cygwin
> process which knows the secret, not a stray native Windows process
> which accidentally hopped on the bandwagon, and we want to exchange
> the credentials so a subsequent SO_PEERCRED call returns correct values.

Ah, okay. I found the original thread you mentioned, and I see that
you sort of discussed some possibilities but nothing was quite
satisfactory at the time, and it was dropped--you mentioned some idea
about exchanging information via pipes, but that was a bit complicated
and half-baked.

Christian described a scheme in that thread which at least seemed like
a way out of the connect hanging problem, and also improved the
security (I think) by having separate server and client secrets, so
that a malicious server could not gain the socket secret from the
client.  But he also worried:

> The only drawback which remains is that the client performs the send()
> before first recv() unconditionally. It will realize the bad server secret
> lately on first recv().

Though you wrote:

> Yeah, but it might be better than nothing and if it avoids the hangs,
> even better.

Which is sort of how I feel, though I do appreciate the security
implication.  One workaround to that which I think might be relatively
simple:  In Christian's scheme, after a connect() the client would be
in a "connected but secret missing" state.  What I would propose
adding is that the client then fires up a thread to wait on receiving
the server's secret (which it would send after receiving the client's
secret in an accept()).  Meanwhile, while the cliet is in the "secret
missing" state, any subsequent send()s would place the sent data on a
local buffer (no bigger than getsockopt(SO_SNDBUF) ?) that would only
get flushed out to actual WSASendTo calls once the server secret is
received.

The only downside I see to this is the added overhead of having to
start a thread for the purpose of waiting to receive the server's
secret which--in many common cases--would be unneeded since the server
may accept() immediately.  So in that case we might default to
blocking to receive the server's secret, but with a relatively brief
timeout, and then only start up a thread in case the server secret
isn't received quickly.

Best,
Erik

--

Re: [PATCH] FAST_CWD: adjust the initial search scope

2017-01-12 Thread Corinna Vinschen 
On Jan 11 20:48, Johannes Schindelin wrote:
> Hi Corinna,
> 
> On Wed, 11 Jan 2017, Corinna Vinschen wrote:
> 
> > On Jan 11 14:21, Johannes Schindelin wrote:
> > > A *very* recent Windows build adds more code to the preamble of
> > > RtlGetCurrentDirectory_U() so that the previous heuristic failed to
> > > find the call to the locking routine.
> > > 
> > > This only affects the 64-bit version of ntdll, where the 0xe8 byte is
> > > now found at offset 40, not the 32-bit version. However, let's just
> > > double the area we search for said byte for good measure.
> > 
> > any chance to convince the powers that be to open up access to this
> > datastructures without such hacky means?
> 
> I try my best.

Thanks!  Patch pushed.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

[newlib-cygwin] FAST_CWD: adjust the initial search scope

2017-01-12 Thread Corinna Vinschen 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=e5cadbfdcdd8b06932a9503b3c72511b68f03a60

commit e5cadbfdcdd8b06932a9503b3c72511b68f03a60
Author: Johannes Schindelin 
Date:   Wed Jan 11 14:21:31 2017 +0100

FAST_CWD: adjust the initial search scope

A *very* recent Windows build adds more code to the preamble of
RtlGetCurrentDirectory_U() so that the previous heuristic failed to find
the call to the locking routine.

This only affects the 64-bit version of ntdll, where the 0xe8 byte is
now found at offset 40, not the 32-bit version. However, let's just
double the area we search for said byte for good measure.

Signed-off-by: Johannes Schindelin 

Diff:
---
 winsup/cygwin/path.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index c3b304a..ee7636d 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -4034,7 +4034,7 @@ find_fast_cwd_pointer ()
   if (!get_dir || !ent_crit)
 return NULL;
   /* Search first relative call instruction in RtlGetCurrentDirectory_U. */
-  const uint8_t *rcall = (const uint8_t *) memchr (get_dir, 0xe8, 40);
+  const uint8_t *rcall = (const uint8_t *) memchr (get_dir, 0xe8, 80);
   if (!rcall)
 return NULL;
   /* Fetch offset from instruction and compute address of called function.
@@ -4133,7 +4133,7 @@ find_fast_cwd_pointer ()
   if (!get_dir || !ent_crit)
 return NULL;
   /* Search first relative call instruction in RtlGetCurrentDirectory_U. */
-  const uint8_t *rcall = (const uint8_t *) memchr (get_dir, 0xe8, 32);
+  const uint8_t *rcall = (const uint8_t *) memchr (get_dir, 0xe8, 64);
   if (!rcall)
 return NULL;
   /* Fetch offset from instruction and compute address of called function.