RE: Issue with email -a (Zip files)

[Priyanka Joshi]

Thanks Brian!

Can you please let me know if there is any way to check SMTP error logs for the 
email not getting sent.

I am trying to enable the logs but facing issue with inetmgr.dll and 
smtpsnap.dll and not seeing SMTP option under IIS.

PFB updates on the steps shared:

>which email
/usr/bin/email

>email --version
email - By Dean Jones; Version 3.2.3-git

, try putting your xml in a zip file, and see if that works. ==>It worked

>email -b -s "Test zip send" -a test.zip priyanka.jo...@bhnetwork.com

Try renaming the zip file as if xml or something safe

==>Tried renaming to xml but email was not triggered, I will check with the 
network team if there are any restrictions


Regards,
Priyanka

-Original Message-
From: Brian Inglis  
Sent: Friday, January 31, 2020 3:27 AM
To: cygwin@cygwin.com
Cc: Priyanka Joshi 
Subject: Re: Issue with email -a (Zip files)

On 2020-01-30 02:21, Priyanka Joshi wrote:
> I am facing issue when I am trying to send zip file as attachment, 
> same command works fine for xml file.
> 
> PFB commands for reference:
> 
> Below command worked fine and sent testng.xml as attachment email -s 
> "BHN Test Automation Report" -a testng.xml 
> priyanka.jo...@bhnetwork.com
> 
> email -s "BHN Test Automation Report" -a allure-report.zip 
> priyanka.jo...@bhnetwork.com ==> Not triggering any email and not throwing 
> any error.
>
> Please let us know how to debug and fix the zip attachment issue.

Cygwin email requires -b option flag, body text on stdin, or invokes your 
editor for body text entry to send emails.
First, check location, version, and test:

$ which email
/usr/bin/email
$ email --version
email - By Dean Jones; Version 3.2.3-git
$ email -b -s "Test zip send" -a Downloads/zip above-email-address

worked for me, with a random downloaded small zip file, also worked whether I 
echoed or redirected text into stdin, or did neither and typed body text into 
the editor window opened on a tmp file.

Corporate networks often have filters and strict rules about what may be 
included in a zip file, may be both outgoing and incoming; they could even have 
Outlook, other email client, or generic email filters on your desktop system.
Talk to your IT mail and security admins to find out what is filtered where.
Try renaming the zip file as if xml or something safe, and see if that works, 
and if not, try putting your xml in a zip file, and see if that works.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains too much technical 
detail. Reader discretion is advised.

--
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: Pipes bug when spawning non-cygwin processes

[Edward Lam]

On Thu, Jan 30, 2020 at 5:25 PM Takashi Yano 
wrote:

> Probably, this is the same issue as
> https://www.cygwin.com/ml/cygwin/2020-01/msg00093.html.
>
> Please try latest cygwin snapshot.
> https://cygwin.com/snapshots/
>
>
Indeed, this works again after  20202401 snapshot!

Thanks,
-Edward

--
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: sshd sessions hang after cygwin1.dll 3.0.7

[Bill Stewart]

Thank you for the assistance!

I released the latest version of my installer, now available (under
"Releases" tab) here:

https://github.com/Bill-Stewart/Cygwin-OpenSSH

Bill

--
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: sshd sessions hang after cygwin1.dll 3.0.7

[Takashi Yano]

On Thu, 30 Jan 2020 12:33:28 -0700
Bill Stewart wrote:
> On Thu, Jan 30, 2020 at 9:46 AM Takashi Yano wrote:
> > I believe you do not need winpty anymore because newer cygwin
> > utilizes pseudo console in pty.
> 
> Since this package is still used for older OS versions, I will still
> need winpty for now.

Indeed. I was rash.

-- 
Takashi Yano 

--
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: Pipes bug when spawning non-cygwin processes

[Takashi Yano]

On Thu, 30 Jan 2020 14:03:50 -0500
Edward Lam wrote:
> I'm getting a problem where cygwin parent processes spawning non-cygwin
> child processes no longer detect when stdin has been closed. Please see the
> sample python code at the end where I've isolated the problem. I've got
> cygwin's python2 running spawn_bar.py that popen's a native non-cygwin
> python2 running bar.py. The steps to reproduce are to run this command
> using the two files detailed at the end of this email:
> 
> $ python2 spawn_bar.py
> 
> On Windows 10, this command quits right away as expected when using cygwin
> 3.0.7 but hangs when using cygwin 3.1.2 (version number as reported from
> running `cygcheck -c cygwin`).
> 
> Looking through the release logs, nothing sticks out except for the change
> in 3.1.0 that mentions PTY changes. However, when I originally ran into
> this, it wasn't even being done through a terminal but some background
> script.
> 
> Any ideas?

Probably, this is the same issue as
https://www.cygwin.com/ml/cygwin/2020-01/msg00093.html.

Please try latest cygwin snapshot.
https://cygwin.com/snapshots/

-- 
Takashi Yano 

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

How to fix mv under SMB/CIFS?

[René Berber]

Hi,

Main question is how to make mv behave intelligently when used in SMB 
filesystem?


Its probably obvious but "intelligently" in this context means do simple 
move between the same file system (SMB to same SMB), and only  use 
copy-delete under different file systems (usually different computers).


Long story... I changed computers, re-installed Cygwin, and now mv is 
always copying when I use mv.  On the old computer it didn't do that. 
Of course I don't remember if I did something to make it that way on the 
old computer (long time user of Cygwin, and Unix).


Thanks for any pointers, even if it is RTFM, which I have done.
--
R.Berber


--
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: Issue with email -a (Zip files)

[Brian Inglis]

On 2020-01-30 02:21, Priyanka Joshi wrote:
> I am facing issue when I am trying to send zip file as attachment, same 
> command works fine for xml file.
> 
> PFB commands for reference:
> 
> Below command worked fine and sent testng.xml as attachment
> email -s "BHN Test Automation Report" -a testng.xml 
> priyanka.jo...@bhnetwork.com
> 
> email -s "BHN Test Automation Report" -a allure-report.zip 
> priyanka.jo...@bhnetwork.com
> ==> Not triggering any email and not throwing any error.
>
> Please let us know how to debug and fix the zip attachment issue.

Cygwin email requires -b option flag, body text on stdin, or invokes your editor
for body text entry to send emails.
First, check location, version, and test:

$ which email
/usr/bin/email
$ email --version
email - By Dean Jones; Version 3.2.3-git
$ email -b -s "Test zip send" -a Downloads/zip above-email-address

worked for me, with a random downloaded small zip file, also worked whether I
echoed or redirected text into stdin, or did neither and typed body text into
the editor window opened on a tmp file.

Corporate networks often have filters and strict rules about what may be
included in a zip file, may be both outgoing and incoming; they could even have
Outlook, other email client, or generic email filters on your desktop system.
Talk to your IT mail and security admins to find out what is filtered where.
Try renaming the zip file as if xml or something safe, and see if that works,
and if not, try putting your xml in a zip file, and see if that works.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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: headache on build repeatibility: octave vs BLODA ?

[Marco Atzeri]

Am 30.01.2020 um 22:05 schrieb Brian Inglis:

On 2020-01-29 06:46, Takashi Yano wrote:

Hi Marco,

On Wed, 29 Jan 2020 13:19:11 +0100
Marco Atzeri wrote:

As Octave uses gnulib, it is possible that the changes in MS are causing
a different subset of gnulib to be used than before, may be exposing
a latent bug or race.

Unfortunately my old build tree was polluted by mistake, so I can
not directly compare a good build tree versus a failing one.


I found suspicious difference between the working build and the
not-working build.

The not-working build has fflush.o, fseek.o and fseeko.o in
build/libgnu/.libs
directory, while the working build does not.

Also, cygoctave-7.dll of not-working build exports rpl_fflush,
rpl_fseek and rpl_fseeko, while that of the working build does
not.

As a test, I used following patch to forcibly remove the code
setting REPLACE_FSEEKO to 1 in configure script, and rebuilt
octave. This works without segmentation fault.


For these to be considered missing or deficient such that they should be
provided or replaced gnulib must consider Cygwin lacking support for ANSI C
fflush https://www.gnu.org/software/gnulib/MODULES.html#ansic_enh_stdio
and POSIX 2008 fseek and fseeko supporting pipes and 4GB in 32 bit mode
https://www.gnu.org/software/gnulib/MODULES.html#posix_sup
perhaps as a result of incorrect conclusions about Cygwin in autoreconf?



I was able to rebuild 5.1.0 successfully on a x86_64 cygwin1.dll
built from git source.
Nor flush or fseek gnulib modules were built.

During weekend I will replicate with i686.

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: headache on build repeatibility: octave vs BLODA ?

[Brian Inglis]

On 2020-01-29 06:46, Takashi Yano wrote:
> Hi Marco,
> 
> On Wed, 29 Jan 2020 13:19:11 +0100
> Marco Atzeri wrote:
>> As Octave uses gnulib, it is possible that the changes in MS are causing
>> a different subset of gnulib to be used than before, may be exposing
>> a latent bug or race.
>>
>> Unfortunately my old build tree was polluted by mistake, so I can
>> not directly compare a good build tree versus a failing one.
> 
> I found suspicious difference between the working build and the
> not-working build.
> 
> The not-working build has fflush.o, fseek.o and fseeko.o in
> build/libgnu/.libs
> directory, while the working build does not.
> 
> Also, cygoctave-7.dll of not-working build exports rpl_fflush,
> rpl_fseek and rpl_fseeko, while that of the working build does
> not.
> 
> As a test, I used following patch to forcibly remove the code
> setting REPLACE_FSEEKO to 1 in configure script, and rebuilt
> octave. This works without segmentation fault.

For these to be considered missing or deficient such that they should be
provided or replaced gnulib must consider Cygwin lacking support for ANSI C
fflush https://www.gnu.org/software/gnulib/MODULES.html#ansic_enh_stdio
and POSIX 2008 fseek and fseeko supporting pipes and 4GB in 32 bit mode
https://www.gnu.org/software/gnulib/MODULES.html#posix_sup
perhaps as a result of incorrect conclusions about Cygwin in autoreconf?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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: sshd sessions hang after cygwin1.dll 3.0.7

[Bill Stewart]

On Thu, Jan 30, 2020 at 12:33 PM Bill Stewart wrote:

> I added cygwin-console-helper.exe and this resolved it, at least on
> Windows 10. My next step is to test on Server 2012 R2.

Tested, and works fine also on Server 2012 R2. Thanks for the help!

Bill

--
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: sshd sessions hang after cygwin1.dll 3.0.7

[Bill Stewart]

On Thu, Jan 30, 2020 at 9:46 AM Takashi Yano wrote:

> Bill Stewart wrote:
> >
> > When I use cygwin1.dll versions newer than 3.0.7, sshd.exe hangs
> > whenever establishing a connection.
> > ...
> > Any ideas?
>
> You need cygwin-console-helper.exe for newer cygwin pty which
> supports pseudo console.
>
> I believe you do not need winpty anymore because newer cygwin
> utilizes pseudo console in pty.

Excellent, thank you!

I added cygwin-console-helper.exe and this resolved it, at least on
Windows 10. My next step is to test on Server 2012 R2.

Since this package is still used for older OS versions, I will still
need winpty for now.

Thanks!

Bill

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

Pipes bug when spawning non-cygwin processes

[Edward Lam]

Hi Folks,

I'm getting a problem where cygwin parent processes spawning non-cygwin
child processes no longer detect when stdin has been closed. Please see the
sample python code at the end where I've isolated the problem. I've got
cygwin's python2 running spawn_bar.py that popen's a native non-cygwin
python2 running bar.py. The steps to reproduce are to run this command
using the two files detailed at the end of this email:

$ python2 spawn_bar.py

On Windows 10, this command quits right away as expected when using cygwin
3.0.7 but hangs when using cygwin 3.1.2 (version number as reported from
running `cygcheck -c cygwin`).

Looking through the release logs, nothing sticks out except for the change
in 3.1.0 that mentions PTY changes. However, when I originally ran into
this, it wasn't even being done through a terminal but some background
script.

Any ideas?

Thanks,
-Edward

# spawn_bar.py
import os
import subprocess
import sys
python = "python2" # this works
python = "/path/to/native/python2" # this hangs
p = subprocess.Popen([python, 'bar.py'], stdin=subprocess.PIPE)
p.stdin.close()
pid, status = os.waitpid(p.pid, 0)

# bar.py
import sys
for line in sys.stdin:
print 'got: ' + line

--
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: hardlinks on directories?

[Eric Blake]

On 1/30/20 12:15 PM, Ulli Horlacher wrote:

(I am a UNIX senior admin, but have VERY few knowledge on Windows)

UNIX does not support hard links on directories (in opposite to Windows?).


Windows does not either.



Are this directory hard links?


No, rather they are parallel mount points (the same directory mounted 
under two different names).


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org


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

hardlinks on directories?

[Ulli Horlacher]

(I am a UNIX senior admin, but have VERY few knowledge on Windows)

UNIX does not support hard links on directories (in opposite to Windows?). 

I found:

/: uname -a
CYGWIN_NT-10.0 W10dev 3.1.2(0.340/5/3) 2019-12-21 15:25 x86_64 Cygwin

/: ls -ldi /bin /usr/bin
281474976929589 drwxr-xr-x+ 1 admin None 0 Jan 29 16:01 /bin
281474976929589 drwxr-xr-x+ 1 admin None 0 Jan 29 16:01 /usr/bin

/: ls -ldi /lib /usr/lib
281474976929595 drwxr-xr-x+ 1 admin None 0 Jun 15  2018 /lib
281474976929595 drwxr-xr-x+ 1 admin None 0 Jun 15  2018 /usr/lib


Are this directory hard links?
Their content seems to be identical.

(How) can I find out with Cygwin which directories are hard links?
I could run "find / -xdev -type d -printf "%i %p\n" and look for same
inodes. 
Is there a better methode?

/: find / -xdev -type d -printf "%i %p\n" | perl -wne 'push @{$i{$1}},$2 if 
/^(\d+) (.+)/; END { foreach $n (keys %i) { @f = @{$i{$n}}; print "$n: @f\n" if 
scalar(@f) > 1} }' | sort -n | head
2: /proc /cygdrive
281474976929589: /bin /usr/bin
281474976929595: /lib /usr/lib
281474976935384: /lib/pkcs11 /usr/lib/pkcs11
281474976935494: /lib/gawk /usr/lib/gawk
281474976938256: /lib/groff /usr/lib/groff
281474976939240: /lib/security /usr/lib/security
281474976939616: /lib/engines-1.1 /usr/lib/engines-1.1
281474976939876: /lib/sasl2_3 /usr/lib/sasl2_3
281474976940081: /lib/p7zip /usr/lib/p7zip

Not so good... too much hits: 
"/lib/pkcs11 /usr/lib/pkcs11" are already in "/lib /usr/lib"


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<20200130181516.ga29...@tik.uni-stuttgart.de>

--
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: [PATCH 0/3] Some O_PATH fixes

[Ken Brown]

On 1/29/2020 9:22 AM, Corinna Vinschen wrote:

On Jan 29 10:52, Corinna Vinschen wrote:

On Jan 29 03:08, Ken Brown wrote:

On 1/28/2020 3:48 PM, Ken Brown wrote:

On 1/28/2020 2:01 PM, Ken Brown wrote:

On 1/28/2020 12:06 PM, Corinna Vinschen wrote:

As outlined on IRC, I found a problem with the ACLs created on new
FIFOs and frixed that (I think).  However, Cygwin doesn't actually
return the real permissions in stat(), only the constant perms 0666,
kind of like for symlinks.  I didn't have time to look into that yet,
but it would be great if we could fix that, too.


I'll take a look if you don't get to it first.


Two quick thoughts, and then I won't have time to think about this any more
until tomorrow:

First, I wonder why in fstat_fs we're not using the stat handle (i.e., 
pc.handle()).


Ignore this.  I was confused.


Second, in the call to get_file_attribute in fstat_helper
(fhandler_disk_file.cc:478), why do we set the first argument to NULL instead of
using our handle?


The handle is a pipe handle, not the file handle, and the permissions
on the pipe handle were not reflecting the permissions on the file.
The NULL pointer was trying to make sure that the file gets opened
for fetching the security descriptor in get_file_sd().


I pushed a fix for the permission problem, but I didn't touch the
get_file_attribute() call in fstat_helper.  If you think this can
be further streamlined, go ahead.


AFAICT, the handle returned by get_stat_handle() should always be pc.handle(), 
not a pipe handle.  Patch on the way.


Ken

[PATCH] Cygwin: fstat_helper: always use handle in call to get_file_attribute

[Ken Brown]

When fhandler_base::fstat_helper is called, the handle h returned by
get_stat_handle() should be pc.handle() and should be safe to use for
getting the file information.  Previously, the call to
get_file_attribute() for FIFOs set the first argument to NULL instead
of h, thereby forcing the file to be opened for fetching the security
descriptor in get_file_sd().
---
 winsup/cygwin/fhandler_disk_file.cc | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/winsup/cygwin/fhandler_disk_file.cc 
b/winsup/cygwin/fhandler_disk_file.cc
index f362e31e3..ad63af824 100644
--- a/winsup/cygwin/fhandler_disk_file.cc
+++ b/winsup/cygwin/fhandler_disk_file.cc
@@ -394,13 +394,14 @@ fhandler_base::fstat_fs (struct stat *buf)
   return res;
 }
 
+/* Called by fstat_by_handle and fstat_by_name. */
 int __reg2
 fhandler_base::fstat_helper (struct stat *buf)
 {
   IO_STATUS_BLOCK st;
   FILE_COMPRESSION_INFORMATION fci;
-  HANDLE h = get_stat_handle ();
-  PFILE_ALL_INFORMATION pfai = pc.fai ();
+  HANDLE h = get_stat_handle ();  /* Should always be pc.handle(). */
+  pfile_all_information pfai = pc.fai ();
   ULONG attributes = pc.file_attributes ();
 
   to_timestruc_t (>BasicInformation.LastAccessTime, >st_atim);
@@ -475,8 +476,8 @@ fhandler_base::fstat_helper (struct stat *buf)
   else if (pc.issocket ())
 buf->st_mode = S_IFSOCK;
 
-  if (!get_file_attribute (is_fs_special () && !pc.issocket () ? NULL : h, pc,
-  >st_mode, >st_uid, >st_gid))
+  if (!get_file_attribute (h, pc, >st_mode, >st_uid,
+  >st_gid))
 {
   /* If read-only attribute is set, modify ntsec return value */
   if (::has_attribute (attributes, FILE_ATTRIBUTE_READONLY)
-- 
2.21.0

Re: sshd sessions hang after cygwin1.dll 3.0.7

[Takashi Yano]

On Thu, 30 Jan 2020 09:27:34 -0700
Bill Stewart wrote:
> I have created an OpenSSH installer for Windows users:
> 
> https://github.com/Bill-Stewart/Cygwin-OpenSSH
> 
> Basically it includes only the minimum files from Cygwin needed to run
> OpenSSH and has some additional conveniences (the foremost of which is
> to automatically install the service).
> 
> The problem:
> 
> When I use cygwin1.dll versions newer than 3.0.7, sshd.exe hangs
> whenever establishing a connection. Following is the output from 'sshd
> -d':
> 
> debug1: sshd version OpenSSH_8.1, OpenSSL 1.1.1d  10 Sep 2019
> debug1: private host key #0: ssh-rsa SHA256:...
> debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:...
> debug1: private host key #2: ssh-ed25519 SHA256:...
> debug1: rexec_argv[0]='/usr/sbin/sshd'
> debug1: rexec_argv[1]='-d'
> debug1: Bind to port 22 on ::.
> Server listening on :: port 22.
> debug1: Bind to port 22 on 0.0.0.0.
> Server listening on 0.0.0.0 port 22.
> debug1: fd 5 clearing O_NONBLOCK
> debug1: Server will not fork when running in debugging mode.
> debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
> debug1: inetd sockets after dupping: 4, 4
> Connection from  port 52466 on  port 22
> debug1: Local version string SSH-2.0-OpenSSH_8.1
> debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
> debug1: match: OpenSSH_8.0 pat OpenSSH* compat 0x0400
> debug1: permanently_set_uid: 197767/197121 [preauth]
> debug1: list_hostkey_types:
> rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
> [preauth]
> debug1: SSH2_MSG_KEXINIT sent [preauth]
> debug1: SSH2_MSG_KEXINIT received [preauth]
> debug1: kex: algorithm: curve25519-sha256 [preauth]
> debug1: kex: host key algorithm: ecdsa-sha2-nistp256 [preauth]
> debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC:
>  compression: none [preauth]
> debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC:
>  compression: none [preauth]
> debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
> debug1: rekey out after 134217728 blocks [preauth]
> debug1: SSH2_MSG_NEWKEYS sent [preauth]
> debug1: Sending SSH2_MSG_EXT_INFO [preauth]
> debug1: expecting SSH2_MSG_NEWKEYS [preauth]
> debug1: SSH2_MSG_NEWKEYS received [preauth]
> debug1: rekey in after 134217728 blocks [preauth]
> debug1: KEX done [preauth]
> debug1: userauth-request for user  service ssh-connection
> method none [preauth]
> debug1: attempt 0 failures 0 [preauth]
> debug1: user  matched 'User ' at line 142
> debug1: authentication methods list 0: password
> debug1: userauth_send_banner: sent [preauth]
> debug1: authentication methods list 0: password [preauth]
> debug1: userauth-request for user  service ssh-connection
> method password [preauth]
> debug1: attempt 1 failures 0 [preauth]
> Accepted password for  from  port 52466 ssh2
> debug1: monitor_child_preauth:  has been authenticated by
> privileged process
> debug1: monitor_read_log: child log fd closed
> debug1: rekey in after 134217728 blocks
> debug1: rekey out after 134217728 blocks
> debug1: ssh_packet_set_postauth: called
> debug1: active: key options: agent-forwarding port-forwarding pty
> user-rc x11-forwarding
> debug1: Entering interactive session for SSH2.
> debug1: server_init_dispatch
> debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384
> debug1: input_session_request
> debug1: channel 0: new [server-session]
> debug1: session_new: session 0
> debug1: session_open: channel 0
> debug1: session_open: session 0: link with channel 0
> debug1: server_input_channel_open: confirm session
> debug1: server_input_global_request: rtype
> no-more-sessi...@openssh.com want_reply 0
> debug1: server_input_channel_req: channel 0 request pty-req reply 1
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 req pty-req
> debug1: Allocating pty.
> 
> The only resolution is to forcibly terminate the spawned copy of sshd
> (the one spawned by the 'sshd -d' process).
> 
> Server is running Windows 10 v1909.
> 
> I have tested, and the hang occurs in all versions of cygwin1.dll after 3.0.7.
> 
> When I revert back to cygwin1.dll 3.0.7, the problem does not occur,
> and the connection succeeds.
> 
> Any ideas?

You need cygwin-console-helper.exe for newer cygwin pty which
supports pseudo console.

I believe you do not need winpty anymore because newer cygwin
utilizes pseudo console in pty.

-- 
Takashi Yano 

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

sshd sessions hang after cygwin1.dll 3.0.7

[Bill Stewart]

I have created an OpenSSH installer for Windows users:

https://github.com/Bill-Stewart/Cygwin-OpenSSH

Basically it includes only the minimum files from Cygwin needed to run
OpenSSH and has some additional conveniences (the foremost of which is
to automatically install the service).

The problem:

When I use cygwin1.dll versions newer than 3.0.7, sshd.exe hangs
whenever establishing a connection. Following is the output from 'sshd
-d':

debug1: sshd version OpenSSH_8.1, OpenSSL 1.1.1d  10 Sep 2019
debug1: private host key #0: ssh-rsa SHA256:...
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:...
debug1: private host key #2: ssh-ed25519 SHA256:...
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: fd 5 clearing O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 4, 4
Connection from  port 52466 on  port 22
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
debug1: match: OpenSSH_8.0 pat OpenSSH* compat 0x0400
debug1: permanently_set_uid: 197767/197121 [preauth]
debug1: list_hostkey_types:
rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
[preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: algorithm: curve25519-sha256 [preauth]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256 [preauth]
debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC:
 compression: none [preauth]
debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC:
 compression: none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: rekey out after 134217728 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: Sending SSH2_MSG_EXT_INFO [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: rekey in after 134217728 blocks [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user  service ssh-connection
method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: user  matched 'User ' at line 142
debug1: authentication methods list 0: password
debug1: userauth_send_banner: sent [preauth]
debug1: authentication methods list 0: password [preauth]
debug1: userauth-request for user  service ssh-connection
method password [preauth]
debug1: attempt 1 failures 0 [preauth]
Accepted password for  from  port 52466 ssh2
debug1: monitor_child_preauth:  has been authenticated by
privileged process
debug1: monitor_read_log: child log fd closed
debug1: rekey in after 134217728 blocks
debug1: rekey out after 134217728 blocks
debug1: ssh_packet_set_postauth: called
debug1: active: key options: agent-forwarding port-forwarding pty
user-rc x11-forwarding
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch
debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_global_request: rtype
no-more-sessi...@openssh.com want_reply 0
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.

The only resolution is to forcibly terminate the spawned copy of sshd
(the one spawned by the 'sshd -d' process).

Server is running Windows 10 v1909.

I have tested, and the hang occurs in all versions of cygwin1.dll after 3.0.7.

When I revert back to cygwin1.dll 3.0.7, the problem does not occur,
and the connection succeeds.

Any ideas?

Thanks!

Bill

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

[newlib-cygwin] Cygwin: document recent changes

[Ken Brown]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=1cc07f3a3ea162d5f39ffeea54a74147754d3649

commit 1cc07f3a3ea162d5f39ffeea54a74147754d3649
Author: Ken Brown 
Date:   Wed Jan 29 12:09:49 2020 -0500

Cygwin: document recent changes

Diff:
---
 winsup/cygwin/release/3.1.3 | 2 ++
 winsup/doc/new-features.xml | 6 ++
 2 files changed, 8 insertions(+)

diff --git a/winsup/cygwin/release/3.1.3 b/winsup/cygwin/release/3.1.3
index f8752ad..06ed1eb 100644
--- a/winsup/cygwin/release/3.1.3
+++ b/winsup/cygwin/release/3.1.3
@@ -11,6 +11,8 @@ What changed:
 - Support the Linux-specific AT_EMPTY_PATH flag for fchownat(2) and
   fstatat(2).
 
+- Allow AF_LOCAL sockets to be opened with O_PATH.
+
 Bug Fixes:
 --
 
diff --git a/winsup/doc/new-features.xml b/winsup/doc/new-features.xml
index 967c64a..78c7760 100644
--- a/winsup/doc/new-features.xml
+++ b/winsup/doc/new-features.xml
@@ -69,6 +69,12 @@ Support the Linux-specific AT_EMPTY_PATH flag for 
fchownat(2) and
 fstatat(2).
 
 
+
+Allow AF_LOCAL sockets to be opened with O_PATH.  If that flag is not
+set, or if an attempt is made to open a different type of socket, the
+errno is now EOPNOTSUPP instead of ENXIO.
+
+
 
 
 

[newlib-cygwin] Cygwin: AF_LOCAL: fix fcntl and dup if O_PATH is set

[Ken Brown]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=477121317d01b37d0f6c84f7724487ecf8a9fbbe

commit 477121317d01b37d0f6c84f7724487ecf8a9fbbe
Author: Ken Brown 
Date:   Sat Jan 25 13:08:00 2020 -0500

Cygwin: AF_LOCAL: fix fcntl and dup if O_PATH is set

Make fhandler_socket_local::dup and fhandler_socket_local::fcntl (a
new method) call fhandler_base::dup and fhandler_base::fcntl if O_PATH
is set.

We're viewing the socket as a disk file here, but there's no need to
implement the actions of fhandler_disk_file::dup and
fhandler_disk_file::fcntl, which do nothing useful in this case beyond
what the fhandler_base methods do.  (The extra actions are only useful
when I/O is going to be done on the file.)

Diff:
---
 winsup/cygwin/fhandler.h   |  1 +
 winsup/cygwin/fhandler_socket_local.cc | 16 
 2 files changed, 17 insertions(+)

diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
index c54780e..1b477f6 100644
--- a/winsup/cygwin/fhandler.h
+++ b/winsup/cygwin/fhandler.h
@@ -836,6 +836,7 @@ class fhandler_socket_local: public fhandler_socket_wsock
 
   int open (int flags, mode_t mode = 0);
   int close ();
+  int fcntl (int cmd, intptr_t);
   int __reg2 fstat (struct stat *buf);
   int __reg2 fstatvfs (struct statvfs *buf);
   int __reg1 fchmod (mode_t newmode);
diff --git a/winsup/cygwin/fhandler_socket_local.cc 
b/winsup/cygwin/fhandler_socket_local.cc
index 76815a6..8bfba22 100644
--- a/winsup/cygwin/fhandler_socket_local.cc
+++ b/winsup/cygwin/fhandler_socket_local.cc
@@ -628,6 +628,11 @@ fhandler_socket_local::af_local_set_secret (char *buf)
 int
 fhandler_socket_local::dup (fhandler_base *child, int flags)
 {
+  if (get_flags () & O_PATH)
+/* We're viewing the socket as a disk file, but fhandler_base::dup
+   suffices here. */
+return fhandler_base::dup (child, flags);
+
   fhandler_socket_local *fhs = (fhandler_socket_local *) child;
   fhs->set_sun_path (get_sun_path ());
   fhs->set_peer_sun_path (get_peer_sun_path ());
@@ -654,6 +659,17 @@ fhandler_socket_local::close ()
 return fhandler_socket_wsock::close ();
 }
 
+int
+fhandler_socket_local::fcntl (int cmd, intptr_t arg)
+{
+  if (get_flags () & O_PATH)
+/* We're viewing the socket as a disk file, but
+   fhandler_base::fcntl suffices here. */
+return fhandler_base::fcntl (cmd, arg);
+  else
+return fhandler_socket_wsock::fcntl (cmd, arg);
+}
+
 int __reg2
 fhandler_socket_local::fstat (struct stat *buf)
 {

[newlib-cygwin] Cygwin: AF_LOCAL: allow opening with the O_PATH flag

[Ken Brown]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=3a2191653ac979f494aa2797942bd96414cedde8

commit 3a2191653ac979f494aa2797942bd96414cedde8
Author: Ken Brown 
Date:   Thu Jan 23 14:39:15 2020 -0500

Cygwin: AF_LOCAL: allow opening with the O_PATH flag

If that flag is not set, or if an attempt is made to open a different
type of socket, the errno is now EOPNOTSUPP instead of ENXIO.  This is
consistent with POSIX, starting with the 2016 edition.  Earlier
editions were silent on this issue.

Opening is done in a (new) fhandler_socket_local::open method by
calling fhandler_base::open_fs.

Also add a corresponding fhandler_socket_local::close method.

Diff:
---
 winsup/cygwin/fhandler.h   |  2 ++
 winsup/cygwin/fhandler_socket_local.cc | 20 
 2 files changed, 22 insertions(+)

diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
index 80a78d1..c54780e 100644
--- a/winsup/cygwin/fhandler.h
+++ b/winsup/cygwin/fhandler.h
@@ -834,6 +834,8 @@ class fhandler_socket_local: public fhandler_socket_wsock
   int getsockopt (int level, int optname, const void *optval,
  __socklen_t *optlen);
 
+  int open (int flags, mode_t mode = 0);
+  int close ();
   int __reg2 fstat (struct stat *buf);
   int __reg2 fstatvfs (struct statvfs *buf);
   int __reg1 fchmod (mode_t newmode);
diff --git a/winsup/cygwin/fhandler_socket_local.cc 
b/winsup/cygwin/fhandler_socket_local.cc
index f88ced2..e7f4fe6 100644
--- a/winsup/cygwin/fhandler_socket_local.cc
+++ b/winsup/cygwin/fhandler_socket_local.cc
@@ -634,6 +634,26 @@ fhandler_socket_local::dup (fhandler_base *child, int 
flags)
   return fhandler_socket_wsock::dup (child, flags);
 }
 
+int
+fhandler_socket_local::open (int flags, mode_t mode)
+{
+  /* We don't support opening sockets unless O_PATH is specified. */
+  if (flags & O_PATH)
+return open_fs (flags, mode);
+
+  set_errno (EOPNOTSUPP);
+  return 0;
+}
+
+int
+fhandler_socket_local::close ()
+{
+  if (get_flags () & O_PATH)
+return fhandler_base::close ();
+  else
+return fhandler_socket_wsock::close ();
+}
+
 int __reg2
 fhandler_socket_local::fstat (struct stat *buf)
 {

[newlib-cygwin] Cygwin: AF_LOCAL::fstatvfs: use our handle if O_PATH is set

[Ken Brown]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=23cb58af623c457639fdcf97c1990edda0508d5c

commit 23cb58af623c457639fdcf97c1990edda0508d5c
Author: Ken Brown 
Date:   Sat Jan 25 07:45:10 2020 -0500

Cygwin: AF_LOCAL::fstatvfs: use our handle if O_PATH is set

If O_PATH is set, then the fhandler_socket_local object has a handle
that can be used for getting the statvfs information.  Use it by
calling fhandler_base::fstatvfs_by_handle.  Without this change,
fhandler_disk_file::fstatfvs would be called on a new fhandler_disk
object, which would then have to be opened.

Diff:
---
 winsup/cygwin/fhandler_socket_local.cc | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/winsup/cygwin/fhandler_socket_local.cc 
b/winsup/cygwin/fhandler_socket_local.cc
index e7f4fe6..76815a6 100644
--- a/winsup/cygwin/fhandler_socket_local.cc
+++ b/winsup/cygwin/fhandler_socket_local.cc
@@ -675,6 +675,13 @@ fhandler_socket_local::fstatvfs (struct statvfs *sfs)
 {
   if (get_sun_path () && get_sun_path ()[0] == '\0')
 return fhandler_socket_wsock::fstatvfs (sfs);
+  if (get_flags () & O_PATH)
+/* We already have a handle. */
+{
+  HANDLE h = get_handle ();
+  if (h)
+   return fstatvfs_by_handle (h, sfs);
+}
   fhandler_disk_file fh (pc);
   fh.get_device () = FH_FS;
   return fh.fstatvfs (sfs);

[newlib-cygwin] Cygwin: AF_LOCAL: set appropriate errno on system calls

[Ken Brown]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=141437d37440572b5452e941df3d4454f0c4378b

commit 141437d37440572b5452e941df3d4454f0c4378b
Author: Ken Brown 
Date:   Thu Jan 23 15:11:15 2020 -0500

Cygwin: AF_LOCAL: set appropriate errno on system calls

If an AF_LOCAL socket is opened with O_PATH, all socket system calls
that take a file descriptor argument fail on the resulting descriptor.
Make sure that errno is set as on Linux for those calls that are
implemented on Linux.  In almost all cases it is ENOTSOCK.  There are
two exceptions:

- sockatatmark(3); errno is EBADF.

- bindresvport(3); errno is EAFNOSUPPORT if the second argument sin
  (of type struct sockaddr_in *) is non-NULL and satisfies
  sin->sin_family == AF_INET.

Finally, there are two BSD socket system calls implemented on Cygwin
but not Linux: getpeereid(3) and bindresvport_sa(3).  Set errno to
ENOTSOCK for these for consistency with the majority of the other
calls.

Diff:
---
 winsup/cygwin/net.cc | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/winsup/cygwin/net.cc b/winsup/cygwin/net.cc
index 437712c..d9f51bf 100644
--- a/winsup/cygwin/net.cc
+++ b/winsup/cygwin/net.cc
@@ -65,8 +65,11 @@ get (const int fd)
 
   fhandler_socket *const fh = cfd->is_socket ();
 
-  if (!fh)
-set_errno (ENOTSOCK);
+  if (!fh || (fh->get_flags () & O_PATH))
+{
+  set_errno (ENOTSOCK);
+  return NULL;
+}
 
   return fh;
 }
@@ -641,9 +644,17 @@ extern "C" int
 sockatmark (int fd)
 {
   int ret;
+  cygheap_fdget cfd (fd);
 
-  fhandler_socket *fh = get (fd);
-  if (fh && fh->ioctl (SIOCATMARK, ) != -1)
+  if (cfd < 0)
+return -1;
+
+  fhandler_socket *const fh = cfd->is_socket ();
+  if (!fh)
+set_errno (ENOTSOCK);
+  else if (fh->get_flags () & O_PATH)
+set_errno (EBADF);
+  else if (fh->ioctl (SIOCATMARK, ) != -1)
 return ret;
   return -1;
 }

Fwd:

[Damian Harty]

  Cygwin          https://u.to/nQJWFw          
Damian Harty


-- Forwarded message -
From: Damian Harty 
Date: Thursday, January 30, 2020 02:58:08 PM
Subject: 
To:  




  


https://search.yahoo.com/search?p==h198q7kh1kp8sdwk
--
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

Issue with email -a (Zip files)

[Priyanka Joshi]

Hi Team,



I am facing issue when I am trying to send zip file as attachment, same command 
works fine for xml file.



PFB commands for reference:



email -s "BHN Test Automation Report" -a allure-report.zip 
priyanka.jo...@bhnetwork.com  ==> Not 
triggering any email and not throwing any error.





Below command worked fine and sent testng.xml as attachment

email -s "BHN Test Automation Report" -a testng.xml 
priyanka.jo...@bhnetwork.com



Please let us know how to debug and fix the zip attachment issue.



Regards,

Priyanka


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