Re: Texlive Package Problem

[Corinna Vinschen]

On Feb 17 18:47, Ken Brown wrote:
> On 2/17/2015 5:47 PM, Corinna Vinschen wrote:
> >On Feb 17 17:16, Ken Brown wrote:
> >>On 2/17/2015 4:39 PM, Corinna Vinschen wrote:
> >>>On Feb 17 15:02, Ken Brown wrote:
> Index: dump_setup.cc
> ===
> RCS file: /cvs/src/src/winsup/utils/dump_setup.cc,v
> retrieving revision 1.28
> diff -u -p -r1.28 dump_setup.cc
> --- dump_setup.cc   16 Sep 2013 17:01:58 -  1.28
> +++ dump_setup.cc   17 Feb 2015 20:00:40 -
> @@ -396,7 +396,7 @@ check_package_files (int verbose, char *
>    if (!directory_exists (verbose, filename, package))
>  result = false;
>  }
> -  else if (!strncmp (filename, "etc/postinstall/", 16))
> +  else if (strstr (filename, "/postinstall/"))
>  {
>    if (!file_exists (verbose, filename, ".done", package))
>  result = false;
> >>>
> >>>Fine with me.
> >>
> >>Should I go ahead and commit this?  I *think* I have the right to do it [1],
> >>but I've never done it before except for changes to cygwin-pkg-maint.
> >>
> >>Ken
> >>
> >>[1] Since I'm not sure I have the right, I apparently don't, according to
> >>the last sentence at https://cygwin.com/cvs.html.
> >
> >It's a bit harshly written, isn't it?
> >
> >If you checked the cygwin repo out with :pserver:anoncvs, you don't have
> >write access using this local copy of the repo.  If you can check out
> >with the :ext: you probably have write access.
> >If the commit fails, you don't.  Just give it a try and please add a
> >valid ChangeLog entry.
> 
> Done.
> 
> Ken

Thanks,
Corinna

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


pgpcLjLvZgyTp.pgp
Description: PGP signature

Re: ssh-host-config script sends /etc/passwd thru awk

[Corinna Vinschen]

On Feb 17 16:22, Warren Young wrote:
> > On Feb 17, 2015, at 4:02 PM, Corinna Vinschen  
> > wrote:
> > 
> > On Feb 17 15:51, Warren Young wrote:
> >> It seems that the ssh-host-config script isn’t using Corinna’s new
> >> getent package yet.
> 
> > Both scripts are using geten or mkpasswd/mkgroup.
> 
> I was sure I looked into my local copies before answering that
> question.  Maybe I had old versions?
> 
> An /etc/passwd containing only an sshd user certainly does seem like a
> fresh install of 1.7.34, with the entry coming from ssh-*-config,
> though, rather than an upgrade from pre-.34.

It's a bit confusing to talk about the Cygwin version when this is
only about openssh and the csih package.  I'm really busy with other
stuff right now.  I quickly scanned the ssh-*-config scripts again
and they never write a passwd entry so, if anything, it's a problem
in the csih helper script.  Does anybody want to inspect
/usr/share/csih/cygwin-service-installation-helper.sh for this?


Thanks,
Corinna

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


pgpNvWKeWn3XL.pgp
Description: PGP signature

Re: Very slow Cygwin startup on Windows 7

[Andrey Repin]

Greetings, Dennis Hagarty (dehagart)!

>>Could you please do me a favor and repeat the test with a little deviation of
>>my previous suggestion?

>>1. Remove /etc/{nsswitch.conf,passwd,group} files. (Rename, move away - by
>>your choice.)
>>2. Stop cygserver, if it is running, and any other Cygwin-related programs.
>>3. Start the mintty (elevated, if need) with write access to /etc. Supposedly,
>>this will be slow.
>>4. Make sure id -G lists all the groups you're member of.
>>The `id -znG | tr "\0" "\n"` would probably be more visible.
>>5. Repeat the steps from previous suggestion.
>>getent passwd $(id -u) > /etc/passwd
>>getent group $(id -G) > /etc/group
>>printf "%s\n" "passwd: files db" "group: files db" > /etc/nsswitch.conf
>> 6. Close and restart mintty

> After I'd run the id -znG, it found 87 groups.
> Then I did this (even with cygserver running)

> ~ getent passwd $(id -u) > /etc/passwd
> ~ getent group $(id -G) > /etc/group
>   0 [main] getent 48156 transport_layer_pipes::connect: lost connection 
> to cygserver, error = 2

That prompts to repeat the previous question from Corinna: are you by chance
remote from your DC? (VPN connection?)

> ~ wc -l /etc/group
> 58 /etc/group

> Since it seems like cygserver stopped, it took a while to complete.
> Anyway, with cygserver stopped, I ran the getent again elevated and got 83.
> ~ wc -l /etc/group
> 83 /etc/group

83 vs. 87, still not the right number.

> Not really sure how many groups I'm a member of (in another tool), but seems 
> about right.

Anyway, how was the results after these manipulations?


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 18.02.2015, <13:41>

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

[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.3

[Corinna Vinschen]

Hi Cygwin friends and users,


I released another very early TEST version of the next upcoming Cygwin
release.  The version number is 1.7.35-0.3.

This release introduces a revision of the LDAP calls done to fetch
information from the DC.  By limiting the search scope, the calls should
now be faster even in bigger environments.  Please give it a try with
activated "db" settings for passwd and group entries in /etc/nsswitch.conf

  passwd: db
  group: db

Please report back your experience, especially if you're suffering
from "slow startup" problems.


If you're not familiar with the new account information handling
introduced in Cygwin 1.7.34, I suggest to read the new documentation
at https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping


The essential changes in this test release are:

- Trying to speed up LDAP searches by limiting the search scope.

- The default settings for db_home, db_shell, and db_gecos in case
  there's no /etc/nsswitch.conf file, or if they are not mentioned 
  in /etc/nsswitch.conf, are now set to just the fallback, which is

db_home: /home/%U
db_shell: /bin/bash
db_gecos: 

  This means, if you don't set these values in /etc/nsswitch.conf,
  there's no reason for Cygwin to access the DC via LDAP.

- Next, I revamped the code fetching values over LDAP to do the actual
  fetching only if it's really required.  So far, the LDAP call was made
  all the time, even if the settings in /etc/nsswitch.conf didn't
  require that.

- Last but not least, the primary group of the current user account is
  not read anymore from the LDAP call, but simply from the current user
  token of the user.

- Group account requests don't access LDAP at all, unless values
  for the UNIX gid <-> Windows SID mapping are required (see
  https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nfs and
  https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-samba
  for an explanation).

All in all, that *should* have the desired effect to avoid all LDAP
calls to the DC for the current user account and its primary and
supplementary group accounts in the default case, even if you only
use the "db" setting for passwd and groups in /etc/nsswitch.conf:

  passwd: db
  group: db

The only downside for other scenarios is that the default settings
in /etc/nsswitch.conf don't catch the "cygwin desc" settings for
db_home, db_shell, and db_gecos anymore by default.  If you want to
use them, you now have to tweak /etc/nsswitch.conf, but most more
complex scenarios will require that anyway.


Other changes in this release:
==

- New APIs: cabsl, cimagl, creall, finitel, hypotl, sqrtl.

- Fix /proc/cpuinfo multicore info on Intel CPUs.
  Addresses: https://cygwin.com/ml/cygwin-apps/2015-02/msg00077.html

- Generate unique inode number for /dev/tty under all circumstances.
  Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00211.html

- Fix handling of PATH search in execlp and other calls to honor mount flags.
  Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00119.html

- Remove a debug message accidentally printed to the terminal window
  if an application calls fcntl(F_SETFL) erroneously.

- Regression in 1.7.34: acl(SETACL, ...) overwrote the incoming acltent_t
  array for bookkeeping purposes while iterating over its entries.  This
  broke reusing the acl in the calling application (e.g. setfacl).
  Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00304.html

- 64 bit: Export forgotten symbol __mempcpy.
  Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00394.html


To install 32-bit Cygwin use https://cygwin.com/setup-x86.exe
To install 64 bit Cygwin use https://cygwin.com/setup-x86_64.exe

If you're already running a 32 bit version of Cygwin on 64 bit Windows
machines, you can continue to do so.  If you're planning a new install
of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit
Cygwin version, unless you need certain packages not yet available in
the 64 bit release.


Have fun,
Corinna

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

--
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: Very slow Cygwin startup on Windows 7

[Corinna Vinschen]

Hi Dennis,

On Feb 17 10:23, Dennis Hagarty (dehagart) wrote:
> >> Thanks Achim - I've recreated my passwd and group files to be sure.
> >> I checked some domain lookups and they take a second or two for each entry 
> >> - quite slow.
> 
> >> So, I'll leave nsswitch where it is for now and I've started cygserver.
> 
> >If you are accepting suggestions, and up for some experimentation, try this:
> 
> ># getent passwd $(id -u) > /etc/passwd
> ># getent group $(id -G) > /etc/group
> ># echo -e "#\npasswd: files db\ngroup: files db\n" > /etc/nsswitch.conf
> >
> >and start bash without cygserver running. Just for test.
> >The idea is to have "your" groups in files so that in simple case of (just
> >startup" Cygwin don't have to talk to DC all too much. If at all.
> 
> >You'd still need to run cygserver to benefit from long-time caching, though.
> 
> Apologies for my slow response - urgent RFI's.

You didn't reply to my suggestions.  But, anyway.  Due to the nice
report in https://cygwin.com/ml/cygwin/2015-02/msg00511.html I now
came up with a new Cygwin test release 1.7.35-0.3, see
https://cygwin.com/ml/cygwin-announce/2015-02/msg00133.html

Can you please try this test version without cygserver, and with
the passwd and group settings in /etc/nsswitch.conf set to

  passwd: db
  group: db

It would be very interesting to know if this improves the situation for
you.


Thanks,
Corinna

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


pgpLQLsTMg5GL.pgp
Description: PGP signature

Re: slow startup after upgrade

[Corinna Vinschen]

Hi Roger,

On Feb 17 22:32, Corinna Vinschen wrote:
> On Feb 17 19:13, Roger Orr wrote:
> > According to nltest /dclist:
> > Our environment has 6 London based DCs 
> > 
> > According to ldp.exe Live Enterprise Tree we have a tree structure for LDAP.
> > 
> > 6 leaf nodes at the top matching ther 6 DCs
> > 4 leaf nodes under an "AUS" (Australia) node
> > 3 leaf nodes under a "CHI" (Chicago) node
> > and a few more similar to this in other regions.
> > 
> > When running mkpasswd I see active sessions to all the nodes in the tree on
> > port 389 (ldap)
> > 
> > I have tried using Sysinternals ADInsight (with a 32bit cygwin) to see what
> > requests are made with 'echo.exe'
> > 
> > There are two searches shown:
> > 
> > A) RootDSE:LDAP_SCOPE_BASE:(objectclass=*)  (1.113ms)
> > B) :LDAP_SCOPE_SUBTREE:((objectClass=trustedDomain) AND
> > (name=)) (4.426s)
> > 
> > I don't know why the second query is being made with the Australian DNS name
> > but I suspect this is the problem.
> 
> Thanks for doing that!  It's really cool to get this info since it seems
> to point to the culprit.
> 
> It's not the problem that the Australian DNS is mentioned here.  This is
> perfectly valid.  The LDAP query is going to the London DNS DC
> (apparently, I hope that's right in your case) and the query is for
> information on a trusted domain.  It looks like you have a group from
> the australian domain in your user token.  To compute the gid of the
> group, cygwin asks *your* DC for a value called "posixOffset" for *that*
> trusted domain.
> 
> The bottom line is, this is not going to Australia, because all DCs have
> this info for their trusted domains in their own DB so it's a planly
> local query.
> 
> However, that mean this local LDAP query is *extremly* slow.  I changed
> the query now to limit the scope of the database search.  This should speed
> up the request a lot.
> [...etc...]

I just release a new test release, 1.7.35-0.3, see
https://cygwin.com/ml/cygwin-announce/2015-02/msg00133.html

This should speed up the search for the trustedDomain info a lot.

Can you please give it a try and perform your fantastic timing test as
above?


Thanks in advance,
Corinna

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


pgpZIx1uZrKCV.pgp
Description: PGP signature

RE: Very slow Cygwin startup on Windows 7

[Dennis Hagarty (dehagart)]

>>>Could you please do me a favor and repeat the test with a little deviation of
>>>my previous suggestion?

>>>1. Remove /etc/{nsswitch.conf,passwd,group} files. (Rename, move away - by
>>>your choice.)
>>>2. Stop cygserver, if it is running, and any other Cygwin-related programs.
>>>3. Start the mintty (elevated, if need) with write access to /etc. 
>>>Supposedly,
>>>this will be slow.
>>>4. Make sure id -G lists all the groups you're member of.
>>>The `id -znG | tr "\0" "\n"` would probably be more visible.
>>>5. Repeat the steps from previous suggestion.
>>>getent passwd $(id -u) > /etc/passwd
>>>getent group $(id -G) > /etc/group
>>>printf "%s\n" "passwd: files db" "group: files db" > /etc/nsswitch.conf
>>> 6. Close and restart mintty

>> After I'd run the id -znG, it found 87 groups.
>> Then I did this (even with cygserver running)

>> ~ getent passwd $(id -u) > /etc/passwd
>> ~ getent group $(id -G) > /etc/group
>>   0 [main] getent 48156 transport_layer_pipes::connect: lost connection 
>> to cygserver, error = 2

>That prompts to repeat the previous question from Corinna: are you by chance
>remote from your DC? (VPN connection?)

Yes - although it's pretty quick link (and not the other side of the world).
Seems to be a node called  \\ADC-AER1-C1-2 

Pinging adc-aer1-c1-2.cisco.com [173.xx.xxx.xxx] with 32 bytes of data:
Reply from 173.38.200.156: bytes=32 time=36ms TTL=124
Reply from 173.38.200.156: bytes=32 time=44ms TTL=124
Reply from 173.38.200.156: bytes=32 time=37ms TTL=124
Reply from 173.38.200.156: bytes=32 time=56ms TTL=124


>> ~ wc -l /etc/group
>> 58 /etc/group
>
>> Since it seems like cygserver stopped, it took a while to complete.
>> Anyway, with cygserver stopped, I ran the getent again elevated and got 83.
>> ~ wc -l /etc/group
>> 83 /etc/group
>
>83 vs. 87, still not the right number.
>
>> Not really sure how many groups I'm a member of (in another tool), but seems 
>> about right.

>Anyway, how was the results after these manipulations?

Performance now is good - as long as the cygserver is running.
With:
>cmd /v:on /c "echo !TIME! & C:\cygwin64\bin\mintty.exe /bin/echo "test" & echo 
>!TIME!"
12:13:43.53
12:13:43.65 = 0:00.12

Without:
C:\Users\dehagart>cmd /v:on /c "echo !TIME! & C:\cygwin64\bin\mintty.exe 
/bin/echo "test" & echo !TIME!"
12:14:36.28
12:16:24.85 = 1:48.57

Regards
Dennis

--
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: slow startup after upgrade

[Roger Orr]

Hello Corinna,

I've just been trying out both the 2015-02-18 10:30:19/44 UTC and 2015-02-17 
21:27:23/48 UTC patches.

Both are now down to the same timings as with a 'files' entry in 
/etc/nsswitch.cfg, (and there's no detectable speed difference between them.)

The scope restriction in the second query to \System reduces the query time to 
1.1 - 1.3 ms (was 4 seconds) and also it no longer opens 14 TCP/IP sessions to 
various ldap servers around the planet (!)

I note that mkpasswd and mkgroup do still open many sessions to the ldap 
servers, but that may be inevitable. It's not an issue directly, of course, 
since I'll no longer need to make use of these, but it perhaps might indicate 
another place where the ldap queries are sub-optimal.

Thanks for your rapid response on this issue!
Regards,
Roger.

From: Corinna Vinschen [corinna-cyg...@cygwin.com]
Sent: 18 February 2015 11:18
To: cygwin@cygwin.com
Cc: Roger Orr
Subject: Re: slow startup after upgrade

Hi Roger,

On Feb 17 22:32, Corinna Vinschen wrote:
> On Feb 17 19:13, Roger Orr wrote:
> > According to nltest /dclist:
> > Our environment has 6 London based DCs
> >
> > According to ldp.exe Live Enterprise Tree we have a tree structure for LDAP.
> >
> > 6 leaf nodes at the top matching ther 6 DCs
> > 4 leaf nodes under an "AUS" (Australia) node
> > 3 leaf nodes under a "CHI" (Chicago) node
> > and a few more similar to this in other regions.
> >
> > When running mkpasswd I see active sessions to all the nodes in the tree on
> > port 389 (ldap)
> >
> > I have tried using Sysinternals ADInsight (with a 32bit cygwin) to see what
> > requests are made with 'echo.exe'
> >
> > There are two searches shown:
> >
> > A) RootDSE:LDAP_SCOPE_BASE:(objectclass=*)  (1.113ms)
> > B) :LDAP_SCOPE_SUBTREE:((objectClass=trustedDomain) AND
> > (name=)) (4.426s)
> >
> > I don't know why the second query is being made with the Australian DNS name
> > but I suspect this is the problem.
>
> Thanks for doing that!  It's really cool to get this info since it seems
> to point to the culprit.
>
> It's not the problem that the Australian DNS is mentioned here.  This is
> perfectly valid.  The LDAP query is going to the London DNS DC
> (apparently, I hope that's right in your case) and the query is for
> information on a trusted domain.  It looks like you have a group from
> the australian domain in your user token.  To compute the gid of the
> group, cygwin asks *your* DC for a value called "posixOffset" for *that*
> trusted domain.
>
> The bottom line is, this is not going to Australia, because all DCs have
> this info for their trusted domains in their own DB so it's a planly
> local query.
>
> However, that mean this local LDAP query is *extremly* slow.  I changed
> the query now to limit the scope of the database search.  This should speed
> up the request a lot.
> [...etc...]

I just release a new test release, 1.7.35-0.3, see
https://cygwin.com/ml/cygwin-announce/2015-02/msg00133.html

This should speed up the search for the trustedDomain info a lot.

Can you please give it a try and perform your fantastic timing test as
above?


Thanks in advance,
Corinna

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

--
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: Very slow Cygwin startup on Windows 7

[Dennis Hagarty (dehagart)]

Hi Corinna,

>> I ran your commands to recreate /etc/passwd and /etc/group
>
>Ideally passwd and group are set to "db" only for this, just to be sure.
>
>> (they now contain 1 line and 3 lines respectively - before it had
>> about 10 & 21 lines in each) 
>
>Hang on.  getent group $(id -G) only returns three lines?  That's a bit
>weird.  How does the output of `id' look like? 

I seem to get a couple of answers (see my response to Andrey).
I just ran it now and got 83 lines - it took a few mins.

>> To create a bash terminal window (from cmd) takes about 5-6 minutes.
>> cmd /v:on /c "echo !TIME! & C:\cygwin64\bin\mintty.exe /bin/echo "test" & 
>> echo !TIME!"
>> 11:01:20.27
>> 11:06:59.78 = 5:39.51
>
>With a running cygserver, how long did it take the second time?

About 1/10 of the second.

>Can you please check again with the cygwin test release 1.7.35-0.2?
>
>Two tests:
>
>- Set passwd and group to "db" only
>- Set passwd to "files db" and group to "db"
>- Both set to "files db"

Ok, running 1.7.35-0.2

cmd /v:on /c "echo !TIME! & C:\cygwin64\bin\mintty.exe /bin/echo "test" & echo 
!TIME!"
12:31:08.46
12:31:09.93 = 0:01.47

Settings = Both = "db"
About 1.65 seconds

Settings = group = "db", passwd = "files db"
About 1.65 seconds

Settings = group = "files db", passwd = "db"
About 1.50 seconds

Settings = group = "files db", passwd = "files db"
About 1.45 seconds

>I think I'm going to create another test version which adds debug output
>to get timings for the LookupAccountName and LDAP calls.  The long time
>this takes in some environments is really puzzeling me.
>
>Would you be willing to run such a test if I provide you with a debug 
>augmented Cygwin DLL?

Yes, I can do that.

RE: Very slow Cygwin startup on Windows 7

[Dennis Hagarty (dehagart)]

Hi Corinna,

> You didn't reply to my suggestions.  But, anyway.  Due to the nice
>report in https://cygwin.com/ml/cygwin/2015-02/msg00511.html I now
>came up with a new Cygwin test release 1.7.35-0.3, see
>https://cygwin.com/ml/cygwin-announce/2015-02/msg00133.html

Sorry, maybe I got a bit confused - didn't mean to :-)
I replied to your previous entry just now.

It turns out that I can get the same info from Windows with:
Cmd> gpresult /R
And I have 83 items in my security group list - so 83 is correct.

>Can you please try this test version without cygserver, and with
>the passwd and group settings in /etc/nsswitch.conf set to
>
>  passwd: db
>  group: db

> It would be very interesting to know if this improves the situation for you.

Just did it for 1.7.35-0.2 - I haven't seen 0.3 turn up at a mirror site yet.

Cheers
Dennis

Re: ssh-host-config script sends /etc/passwd thru awk

[Achim Gratz]

Corinna Vinschen writes:
> It's a bit confusing to talk about the Cygwin version when this is
> only about openssh and the csih package.  I'm really busy with other
> stuff right now.  I quickly scanned the ssh-*-config scripts again
> and they never write a passwd entry so, if anything, it's a problem
> in the csih helper script.  Does anybody want to inspect
> /usr/share/csih/cygwin-service-installation-helper.sh for this?

How about this (untested)?

--8<---cut here---start->8---
--- /usr/share/csih/cygwin-service-installation-helper.sh.orig  2015-01-08 
16:30:30.0 +0100
+++ /usr/share/csih/cygwin-service-installation-helper.sh   2015-02-18 
12:47:18.487096800 +0100
@@ -88,6 +88,7 @@
 #csih_make_dir
 #csih_get_system_and_admins_ids
 #csih_check_passwd_and_group
+#csih_old_cygwin
 #csih_use_file_etc
 #csih_check_user
 #csih_check_dir_perms
@@ -2017,7 +2018,7 @@
   if [ -z "$csih_ADMINSUID" -o -z "$csih_SYSTEMUID" ]
   then
 csih_warning "It appears that you do not have an entry for the local"
-csih_warning "ADMINISTRATORS (group) and/or SYSTEM sids in /etc/passwd."
+csih_warning "ADMINISTRATORS (group) and/or SYSTEM sids."
 csih_warning ""
 csih_warning "Use the 'mkpasswd' utility to generate it or allow \"db\""
 csih_warning "search of passwd accounts in /etc/nsswitch.conf"
@@ -2042,37 +2043,54 @@
   csih_stacktrace "${@}"
   $_csih_trace
   local ret=0
-  # Check for mkpasswd only valid up to Cygwin 1.7.32 */
-  if [ "$(/usr/bin/id -gn)" = "mkpasswd" ]
-  then
-csih_warning "It appears that you do not have an entry for your user ID"
-csih_warning "in /etc/passwd."
-csih_warning ""
-csih_warning "If so, use the 'mkpasswd' utility to generate an"
-csih_warning "entry for your User ID in the password file:"
-csih_warning "   mkpasswd -l -u User_ID >> /etc/passwd"
-csih_warning "or"
-csih_warning "   mkpasswd -d -u User_ID >> /etc/passwd."
-csih_warning ""
-_csih_warning_for_etc_file passwd
-ret=1
-  fi
-
-  # Check for mkgroup only valid up to Cygwin 1.7.32 */
-  if [ "$(/usr/bin/id -gn)" = mkgroup ]
-  then
-csih_warning "It appears that you do not have an entry for your group ID"
-csih_warning "in /etc/group.  If this check is incorrect, then re-run"
-csih_warning "this script with the '-f' command-line option."
-csih_warning ""
-csih_warning "Otherwise, use the 'mkgroup' utility to generate an"
-csih_warning "entry for your group ID in the password file:"
-csih_warning "   mkgroup -l -g Group_id  >> /etc/group"
-csih_warning "or"
-csih_warning "   mkgroup -d -g Group_id >> /etc/group."
-csih_warning ""
-_csih_warning_for_etc_file group
-ret=1
+  # Check for mkpasswd/mkgroup only valid up to Cygwin 1.7.33
+  if csih_old_cygwin
+if [ "$(/usr/bin/id -un)" = "mkpasswd" ]
+then
+  csih_warning "It appears that you do not have an entry for your user ID"
+  csih_warning "in /etc/passwd."
+  csih_warning ""
+  csih_warning "If so, use the 'mkpasswd' utility to generate an"
+  csih_warning "entry for your User ID in the password file:"
+  csih_warning "   mkpasswd -l -u User_ID >> /etc/passwd"
+  csih_warning "or"
+  csih_warning "   mkpasswd -d -u User_ID >> /etc/passwd."
+  csih_warning ""
+  _csih_warning_for_etc_file passwd
+  ret=1
+fi
+if [ "$(/usr/bin/id -gn)" = mkgroup ]
+then
+  csih_warning "It appears that you do not have an entry for your group ID"
+  csih_warning "in /etc/group.  If this check is incorrect, then re-run"
+  csih_warning "this script with the '-f' command-line option."
+  csih_warning ""
+  csih_warning "Otherwise, use the 'mkgroup' utility to generate an"
+  csih_warning "entry for your group ID in the password file:"
+  csih_warning "   mkgroup -l -g Group_id  >> /etc/group"
+  csih_warning "or"
+  csih_warning "   mkgroup -d -g Group_id >> /etc/group."
+  csih_warning ""
+  _csih_warning_for_etc_file group
+  ret=1
+fi
+  else
+if ! getent passwd $(/usr/bin/id -un) >/dev/null 2>&1
+then
+  csih_warning "It appears that you do not have an entry for your user ID"
+  csih_warning "in the user account database."
+  csih_warning ""
+  csih_warning "Please check the settings in /etc/nsswitch.conf."
+  ret=1
+fi
+if ! getent group $(/usr/bin/id -gn) >/dev/null 2>&1
+then
+  csih_warning "It appears that you do not have an entry for your user ID"
+  csih_warning "in the group account database."
+  csih_warning ""
+  csih_warning "Please check the settings in /etc/nsswitch.conf."
+  ret=1
+fi
   fi
   return "${ret}"
 } # === End of csih_check_passwd_and_group() === #
@@ -2493,6 +2511,29 @@
 readonly -f _csih_setup
 
 # ==
+# Routine: csih_old_cygwin
+#   Ch

Re: ssh-host-config script sends /etc/passwd thru awk

[Achim Gratz]

Achim Gratz writes:
> +  if csih_old_cygwin

Missing a "then" here of course…

> +if [ "$(/usr/bin/id -un)" = "mkpasswd" ]

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

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

--
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: ssh-host-config script sends /etc/passwd thru awk

[Andrey Repin]

Greetings, Corinna Vinschen!

> On Feb 17 16:22, Warren Young wrote:
>> > On Feb 17, 2015, at 4:02 PM, Corinna Vinschen  
>> > wrote:
>> > 
>> > On Feb 17 15:51, Warren Young wrote:
>> >> It seems that the ssh-host-config script isn’t using Corinna’s new
>> >> getent package yet.
>> 
>> > Both scripts are using geten or mkpasswd/mkgroup.
>> 
>> I was sure I looked into my local copies before answering that
>> question.  Maybe I had old versions?
>> 
>> An /etc/passwd containing only an sshd user certainly does seem like a
>> fresh install of 1.7.34, with the entry coming from ssh-*-config,
>> though, rather than an upgrade from pre-.34.

> It's a bit confusing to talk about the Cygwin version when this is
> only about openssh and the csih package.  I'm really busy with other
> stuff right now.  I quickly scanned the ssh-*-config scripts again
> and they never write a passwd entry so, if anything, it's a problem
> in the csih helper script.  Does anybody want to inspect
> /usr/share/csih/cygwin-service-installation-helper.sh for this?

I'm on it, and the only place, where awk is ever called so far in relation to
these files is csih_use_file_etc

So far it seems the user need to upgrade or reinstall his openssh package.
I'm off to try and set openssh on my newest VM, that have Cygwin first
installed after 1.7.34 release.
I'll be back.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 18.02.2015, <15:01>

Sorry for my terrible english...

Setup and perl

[Angelo Graziosi]

Today I run setup to update Cygwin and it wanted to install perl_base as 
dependency (I don't remember which version). OK.


Then I saw that there was a new test release of Cygwin (1.7.35-03) and 
since I was using 1.7.35-2, I re-run setup to install it. And after 
choosing only 1.7.35-03 in Exp/Pendig, setup wanted to install another 
time perl_base as dependency. This time I took note: it was version 
5.14.4-3 (setup.ini says it is in TEST). OK.


For sanity check, I re-run setup and found in Curr/Pendig a version of 
file and... oops perl_autorebase-001001, being 5.14.4-3 currently 
installed...


I wonder if all this is to be expected...


Ciao,
 Angelo.

--
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: slow startup after upgrade

[Corinna Vinschen]

Hi Roger,

On Feb 18 11:26, Roger Orr wrote:
> Hello Corinna,
> 
> I've just been trying out both the 2015-02-18 10:30:19/44 UTC and
> 2015-02-17 21:27:23/48 UTC patches.
> 
> Both are now down to the same timings as with a 'files' entry in
> /etc/nsswitch.cfg, (and there's no detectable speed difference between
> them.)
> 
> The scope restriction in the second query to \System reduces the query
> time to 1.1 - 1.3 ms (was 4 seconds)

Wow!  That's what I had hoped for but it's really incredible to read that.

> and also it no longer opens 14
> TCP/IP sessions to various ldap servers around the planet (!)

Uh, that might be the result of the other changes which don't open an
LDAP connection to fetch group info.  14 connections probably means,
you're in 14 groups in other domains than your login domain.

> I note that mkpasswd and mkgroup do still open many sessions to the
> ldap servers, but that may be inevitable.

Cygwin is using a bulk LDAP request, fetching 100 entries in each call.
I'm not quite sure how all that works under the LDAP library hood, but
one one hand mkpasswd/mkgroup need to make a lot of requests if you
enumerate your entire organization, and every domain needs its own
connection.

> It's not an issue directly,
> of course, since I'll no longer need to make use of these, but it
> perhaps might indicate another place where the ldap queries are
> sub-optimal.

The enumeration queries got the same treatment, so I assume this is
really just a result of having to enumerate all the domains.

> Thanks for your rapid response on this issue!

Same to you!  I'm glad to get testers in such big environments since, as
I said, it's kinda hard to test big stuff in a tiny domain like mine at
home :}

Final question:  Given the above improvement, are you going to run in
"db" only setting for the time being?  That would make some good long
time test... :)


Thanks a bunch,
Corinna

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


pgpf3ysowIOQJ.pgp
Description: PGP signature

Re: Very slow Cygwin startup on Windows 7

[Corinna Vinschen]

On Feb 18 11:56, Dennis Hagarty (dehagart) wrote:
> Hi Corinna,
> 
> > You didn't reply to my suggestions.  But, anyway.  Due to the nice
> >report in https://cygwin.com/ml/cygwin/2015-02/msg00511.html I now
> >came up with a new Cygwin test release 1.7.35-0.3, see
> >https://cygwin.com/ml/cygwin-announce/2015-02/msg00133.html
> 
> Sorry, maybe I got a bit confused - didn't mean to :-)
> I replied to your previous entry just now.
> 
> It turns out that I can get the same info from Windows with:
> Cmd> gpresult /R
> And I have 83 items in my security group list - so 83 is correct.
> 
> >Can you please try this test version without cygserver, and with
> >the passwd and group settings in /etc/nsswitch.conf set to
> >
> >  passwd: db
> >  group: db
> 
> > It would be very interesting to know if this improves the situation for you.
> 
> Just did it for 1.7.35-0.2 - I haven't seen 0.3 turn up at a mirror site yet.

It's only just uploaded so it might take another while, depending
on your mirrors.  According to Roger's results in
https://cygwin.com/ml/cygwin/2015-02/msg00511.html and
https://cygwin.com/ml/cygwin/2015-02/msg00543.html, the real problem
hadn't been fixed in the 0.2 test release, so you might give 0.3
another chance.


Thanks,
Corinna

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


pgpVxX3sQGvQf.pgp
Description: PGP signature

Re: ssh-host-config script sends /etc/passwd thru awk

[Corinna Vinschen]

On Feb 18 13:00, Achim Gratz wrote:
> Corinna Vinschen writes:
> > It's a bit confusing to talk about the Cygwin version when this is
> > only about openssh and the csih package.  I'm really busy with other
> > stuff right now.  I quickly scanned the ssh-*-config scripts again
> > and they never write a passwd entry so, if anything, it's a problem
> > in the csih helper script.  Does anybody want to inspect
> > /usr/share/csih/cygwin-service-installation-helper.sh for this?
> 
> How about this (untested)?

Thanks for looking and the patch.  However, I seem to miss the point:

> +  if csih_old_cygwin
> +if [ "$(/usr/bin/id -un)" = "mkpasswd" ]

At this point, the csih_old_cygwin test should be unnecessary because
the "mkpasswd" and "mkgroup" accounts names are not generated at all
by Cygwin >= 1.7.34.  So the test for the name alone should be sufficient.
OTOH, the csih_old_cygwin test won't hurt either, of course.

>  # ==
> +# Routine: csih_old_cygwin
> +#   Check Cygwin version, account databases are avaiable since 1.7.34
> +#   On Cygwin versions <= 1.7.33 return 0
> +#   On Cygwin versions >  1.7.33 return 1
> +# ==
> +csih_old_cygwin()
> +{
> +  local old_cygwin
> +
> +  /usr/bin/uname -r |
> +  /usr/bin/awk -F. '{
> + if ( $1 < 1 || \
> + ($1 == 1 && $2 < 7) || \
> + ($1 == 1 && $2 == 7 && strtonum($3) <= 33))
> +   exit 0;
> + exit 1;
> +   }'
> +  old_cygwin=$?
> +  return ${old_cygwin}
> +} # === End of csih_old_cygwin() === #
> +readonly -f csih_old_cygwin
> +
> +# ==
>  # Routine: csih_use_file_etc passwd|group
>  #   Check if /etc/passwd or /etc/group file is in use.
>  #   On Cygwin versions < 1.7.33, files are always used.
> @@ -2517,18 +2558,12 @@
>then
>  csih_error 'Script error: csih_use_file_etc requires argument "passwd" 
> or "group".'
>fi
> -  /usr/bin/uname -r |
> -  /usr/bin/awk -F. '{
> - if ($1 < 1 || \
> - ($1 == 1 && $2 < 7) || \
> - ($1 == 1 && $2 == 7 && strtonum($3) <= 33))
> -   exit 0;
> - exit 1;
> -   }'
> -  use_file=$?
> +  csih_old_cygwin ; use_file=$?
>if [ ${use_file} -ne 0 -a -f /etc/nsswitch.conf ]
>then
> -grep -Eq "^${file}:[^#]*\" /etc/nsswitch.conf || use_file=0
> +grep -Eq "^${file}:" /etc/nsswitch.conf &&
> +  grep -Eq "^${file}:[^#]*\" /etc/nsswitch.conf ||
> +   use_file=0

And here, the test for the version is moved into the csih_old_cygwin
function.  So far, so good, but... in how far does this change the
result of csih_use_file_etc?!?  Assuming the expression has a bug,
wouldn't this still be the case, and the mkpasswd calls in
csih_create_privileged_user and csih_create_unprivileged_user
would still write the entry to /etc/passwd?

Can you explain what I'm missing?


Thanks,
Corinna

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


pgpvTdB8807Jp.pgp
Description: PGP signature

Re: ssh-host-config script sends /etc/passwd thru awk

[Corinna Vinschen]

On Feb 18 15:05, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> > On Feb 17 16:22, Warren Young wrote:
> >> > On Feb 17, 2015, at 4:02 PM, Corinna Vinschen 
> >> >  wrote:
> >> > 
> >> > On Feb 17 15:51, Warren Young wrote:
> >> >> It seems that the ssh-host-config script isn’t using Corinna’s new
> >> >> getent package yet.
> >> 
> >> > Both scripts are using geten or mkpasswd/mkgroup.
> >> 
> >> I was sure I looked into my local copies before answering that
> >> question.  Maybe I had old versions?
> >> 
> >> An /etc/passwd containing only an sshd user certainly does seem like a
> >> fresh install of 1.7.34, with the entry coming from ssh-*-config,
> >> though, rather than an upgrade from pre-.34.
> 
> > It's a bit confusing to talk about the Cygwin version when this is
> > only about openssh and the csih package.  I'm really busy with other
> > stuff right now.  I quickly scanned the ssh-*-config scripts again
> > and they never write a passwd entry so, if anything, it's a problem
> > in the csih helper script.  Does anybody want to inspect
> > /usr/share/csih/cygwin-service-installation-helper.sh for this?
> 
> I'm on it, and the only place, where awk is ever called so far in relation to
> these files is csih_use_file_etc
> 
> So far it seems the user need to upgrade or reinstall his openssh package.
> I'm off to try and set openssh on my newest VM, that have Cygwin first
> installed after 1.7.34 release.
> I'll be back.

Looking forward to it.


Thanks,
Corinna

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


pgpZOAWqpsKzJ.pgp
Description: PGP signature

[ANNOUNCEMENT] Updated: file-5.22-1 [SECURITY]

[Corinna Vinschen]

I've updated the Cygwin version of file to 5.22-1.

This is an update to the latest official upstream version.  This
release fixes various CVE bugs:

  CVE-2014-9653: malformed elf file causes access to uninitialized memory
  CVE-2014-9621: limit string printing to 100 chars
  CVE-2014-9620: limit the number of ELF notes processed
  CVE-2014-8116: multiple denial of service issues (resource consumption)
  CVE-2014-8117: denial of service issue (resource consumption)


Have fun,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat, Inc.

--
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: Setup and perl

[Achim Gratz]

Angelo Graziosi writes:
> Today I run setup to update Cygwin and it wanted to install perl_base
> as dependency (I don't remember which version). OK.
>
> Then I saw that there was a new test release of Cygwin (1.7.35-03) and
> since I was using 1.7.35-2, I re-run setup to install it. And after
> choosing only 1.7.35-03 in Exp/Pendig, setup wanted to install another
> time perl_base as dependency. This time I took note: it was version
> 5.14.4-3 (setup.ini says it is in TEST). OK.
>
> For sanity check, I re-run setup and found in Curr/Pendig a version of
> file and... oops perl_autorebase-001001, being 5.14.4-3 currently
> installed...
>
> I wonder if all this is to be expected...

Sort of, now that you say it… the test version of perl does require
perl_base as a dependency, but that requirement also carries to all
other versions unfortunately.  I'll upload an empty package for current.

As for perl_autorebase, it does not matter which version you install and
the perl_autorebase-001001-1 package will be removed soon.


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

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

--
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: ssh-host-config script sends /etc/passwd thru awk

[Achim Gratz]

Corinna Vinschen writes:
>> +  csih_old_cygwin ; use_file=$?
>>if [ ${use_file} -ne 0 -a -f /etc/nsswitch.conf ]
>>then
>> -grep -Eq "^${file}:[^#]*\" /etc/nsswitch.conf || use_file=0
>> +grep -Eq "^${file}:" /etc/nsswitch.conf &&
>> +  grep -Eq "^${file}:[^#]*\" /etc/nsswitch.conf ||
>> +   use_file=0
>
> And here, the test for the version is moved into the csih_old_cygwin
> function.  So far, so good, but... in how far does this change the
> result of csih_use_file_etc?!?  Assuming the expression has a bug,
> wouldn't this still be the case, and the mkpasswd calls in
> csih_create_privileged_user and csih_create_unprivileged_user
> would still write the entry to /etc/passwd?
>
> Can you explain what I'm missing?

The old test wrote to /etc/{passwd,group} when use_file!=1,
/etc/nsswitch.conf existed and did not have a line for either passwd or
group or if that line had no "db" on it.  If the line is missing
altogether, then files should still not be used since the default is
"files db", only when the line exists and omits "db".  I think…


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

Factory and User Sound Singles for Waldorf Blofeld:
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

Re: ssh-host-config script sends /etc/passwd thru awk

[Achim Gratz]

Achim Gratz writes:
> The old test wrote to /etc/{passwd,group} when use_file!=1,
…make that  -^!=0


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

Factory and User Sound Singles for Waldorf Blofeld:
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

Re: ssh-host-config script sends /etc/passwd thru awk

[Corinna Vinschen]

On Feb 18 14:15, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> +  csih_old_cygwin ; use_file=$?
> >>if [ ${use_file} -ne 0 -a -f /etc/nsswitch.conf ]
> >>then
> >> -grep -Eq "^${file}:[^#]*\" /etc/nsswitch.conf || use_file=0
> >> +grep -Eq "^${file}:" /etc/nsswitch.conf &&
> >> +  grep -Eq "^${file}:[^#]*\" /etc/nsswitch.conf ||
> >> +   use_file=0
> >
> > And here, the test for the version is moved into the csih_old_cygwin
> > function.  So far, so good, but... in how far does this change the
> > result of csih_use_file_etc?!?  Assuming the expression has a bug,
> > wouldn't this still be the case, and the mkpasswd calls in
> > csih_create_privileged_user and csih_create_unprivileged_user
> > would still write the entry to /etc/passwd?
> >
> > Can you explain what I'm missing?
> 
> The old test wrote to /etc/{passwd,group} when use_file!=1,
> /etc/nsswitch.conf existed and did not have a line for either passwd or
> group or if that line had no "db" on it.  If the line is missing
> altogether, then files should still not be used since the default is
> "files db", only when the line exists and omits "db".  I think…

Uh, the penny is dropping... in slow motion...

Hang on, let me try to rephrase what we need here, without letting
myself getting distracted by the code nor your patch.  I'm firmly
securing my blinders...

- If we have an old Cygwin version <= 1.7.33 ==> write to /etc/passwd

- Otherwise, if /etc/nsswitch.conf is missing, don't write.

- Otherwise, if /etc/nsswitch.conf is missing the "passwd:" entry,
  the default is "files db", don't write.

- Otherwise, if "passwd" contains "db", don't write.

- Otherwise, write.

Now lets' check the expression:

   csih_old_cygwin ; use_file=$?
   if [ ${use_file} -ne 0 -a -f /etc/nsswitch.conf ]
   then
 grep -Eq "^${file}:" /etc/nsswitch.conf &&
   grep -Eq "^${file}:[^#]*\" /etc/nsswitch.conf ||
 use_file=0

Old version?  use_file is 0
New version but /etc/nsswitch.conf is missing?  use_file = 1
/etc/nsswitch.conf does not contain a "passwd" line?  use_file = 1
/etc/nsswitch.conf contain a "passwd" line but no "db"?  use_file = 0
otherwise use_file = 1

Yup, that looks right.  Thanks for explaining.  I guess that should
help us along.  If you check this change in, I will release a new
csih version asap.


Thank you!
Corinna

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


pgpiAU358QYBy.pgp
Description: PGP signature

Re: ssh-host-config script sends /etc/passwd thru awk

[Andrey Repin]

Greetings, Corinna Vinschen!

>> >> >> It seems that the ssh-host-config script isn’t using Corinna’s new
>> >> >> getent package yet.
>> >> 
>> >> > Both scripts are using geten or mkpasswd/mkgroup.
>> >> 
>> >> I was sure I looked into my local copies before answering that
>> >> question.  Maybe I had old versions?
>> >> 
>> >> An /etc/passwd containing only an sshd user certainly does seem like a
>> >> fresh install of 1.7.34, with the entry coming from ssh-*-config,
>> >> though, rather than an upgrade from pre-.34.
>> 
>> > It's a bit confusing to talk about the Cygwin version when this is
>> > only about openssh and the csih package.  I'm really busy with other
>> > stuff right now.  I quickly scanned the ssh-*-config scripts again
>> > and they never write a passwd entry so, if anything, it's a problem
>> > in the csih helper script.  Does anybody want to inspect
>> > /usr/share/csih/cygwin-service-installation-helper.sh for this?
>> 
>> I'm on it, and the only place, where awk is ever called so far in relation to
>> these files is csih_use_file_etc
>> 
>> So far it seems the user need to upgrade or reinstall his openssh package.
>> I'm off to try and set openssh on my newest VM, that have Cygwin first
>> installed after 1.7.34 release.
>> I'll be back.

> Looking forward to it.

You were right, the offender is the ssh-user-config, the check_user_homedir()
function.
The openssh is the 64-bit version, as in the stackexchange user's case.
The issue is interesting, though. When I first installed the openssh, it
offered me "prev" version of the package, even though I was installing from
the net. Re-running the installer picked the "current" version.
Setup.exe glitch?


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 18.02.2015, <16:17>

Sorry for my terrible english...

Re: Very slow Cygwin startup on Windows 7

[Andrey Repin]

Greetings, Dennis Hagarty (dehagart)!

Could you please do me a favor and repeat the test with a little deviation 
of
my previous suggestion?

1. Remove /etc/{nsswitch.conf,passwd,group} files. (Rename, move away - by
your choice.)
2. Stop cygserver, if it is running, and any other Cygwin-related programs.
3. Start the mintty (elevated, if need) with write access to /etc. 
Supposedly,
this will be slow.
4. Make sure id -G lists all the groups you're member of.
The `id -znG | tr "\0" "\n"` would probably be more visible.
5. Repeat the steps from previous suggestion.
getent passwd $(id -u) > /etc/passwd
getent group $(id -G) > /etc/group
printf "%s\n" "passwd: files db" "group: files db" > /etc/nsswitch.conf
 6. Close and restart mintty

>>> After I'd run the id -znG, it found 87 groups.
>>> Then I did this (even with cygserver running)

>>> ~ getent passwd $(id -u) > /etc/passwd
>>> ~ getent group $(id -G) > /etc/group
>>>   0 [main] getent 48156 transport_layer_pipes::connect: lost connection 
>>> to cygserver, error = 2

>>That prompts to repeat the previous question from Corinna: are you by chance
>>remote from your DC? (VPN connection?)

> Yes - although it's pretty quick link (and not the other side of the world).
> Seems to be a node called  \\ADC-AER1-C1-2 

> Pinging adc-aer1-c1-2.cisco.com [173.xx.xxx.xxx] with 32 bytes of data:
> Reply from 173.38.200.156: bytes=32 time=36ms TTL=124
> Reply from 173.38.200.156: bytes=32 time=44ms TTL=124
> Reply from 173.38.200.156: bytes=32 time=37ms TTL=124
> Reply from 173.38.200.156: bytes=32 time=56ms TTL=124


>>> ~ wc -l /etc/group
>>> 58 /etc/group
>>
>>> Since it seems like cygserver stopped, it took a while to complete.
>>> Anyway, with cygserver stopped, I ran the getent again elevated and got 83.
>>> ~ wc -l /etc/group
>>> 83 /etc/group
>>
>>83 vs. 87, still not the right number.
>>
>>> Not really sure how many groups I'm a member of (in another tool), but 
>>> seems about right.

>>Anyway, how was the results after these manipulations?

> Performance now is good - as long as the cygserver is running.
> With:
>>cmd /v:on /c "echo !TIME! & C:\cygwin64\bin\mintty.exe /bin/echo "test" & 
>>echo !TIME!"
> 12:13:43.53
> 12:13:43.65 = 0:00.12

> Without:
> C:\Users\dehagart>cmd /v:on /c "echo !TIME! & C:\cygwin64\bin\mintty.exe 
> /bin/echo "test" & echo !TIME!"
> 12:14:36.28
> 12:16:24.85 = 1:48.57

Thank you. Not the results I was hoping for, but thank you anyway.
Please continue investigation with Corinna.
And be sure your help is much appreciated :)


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 18.02.2015, <16:40>

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

RE: Very slow Cygwin startup on Windows 7

[Dennis Hagarty (dehagart)]

Thanks for your assistance Andrey...

I/we use this tool every day and we really take for granted how much effort 
people put into making it work.

I'm checking the mirror every little while to see when .0.3 pops up.

Cheers
Dennis 

-Original Message-
From: Andrey Repin [mailto:anrdae...@yandex.ru] 
Sent: Wednesday, 18 February 2015 14:42
To: Dennis Hagarty (dehagart); cygwin@cygwin.com
Subject: Re: Very slow Cygwin startup on Windows 7

Greetings, Dennis Hagarty (dehagart)!

Could you please do me a favor and repeat the test with a little deviation 
of
my previous suggestion?

1. Remove /etc/{nsswitch.conf,passwd,group} files. (Rename, move away - by
your choice.)
2. Stop cygserver, if it is running, and any other Cygwin-related programs.
3. Start the mintty (elevated, if need) with write access to /etc. 
Supposedly,
this will be slow.
4. Make sure id -G lists all the groups you're member of.
The `id -znG | tr "\0" "\n"` would probably be more visible.
5. Repeat the steps from previous suggestion.
getent passwd $(id -u) > /etc/passwd
getent group $(id -G) > /etc/group
printf "%s\n" "passwd: files db" "group: files db" > /etc/nsswitch.conf
 6. Close and restart mintty

>>> After I'd run the id -znG, it found 87 groups.
>>> Then I did this (even with cygserver running)

>>> ~ getent passwd $(id -u) > /etc/passwd
>>> ~ getent group $(id -G) > /etc/group
>>>   0 [main] getent 48156 transport_layer_pipes::connect: lost connection 
>>> to cygserver, error = 2

>>That prompts to repeat the previous question from Corinna: are you by chance
>>remote from your DC? (VPN connection?)

> Yes - although it's pretty quick link (and not the other side of the world).
> Seems to be a node called  \\ADC-AER1-C1-2 

> Pinging adc-aer1-c1-2.cisco.com [173.xx.xxx.xxx] with 32 bytes of data:
> Reply from 173.38.200.156: bytes=32 time=36ms TTL=124
> Reply from 173.38.200.156: bytes=32 time=44ms TTL=124
> Reply from 173.38.200.156: bytes=32 time=37ms TTL=124
> Reply from 173.38.200.156: bytes=32 time=56ms TTL=124


>>> ~ wc -l /etc/group
>>> 58 /etc/group
>>
>>> Since it seems like cygserver stopped, it took a while to complete.
>>> Anyway, with cygserver stopped, I ran the getent again elevated and got 83.
>>> ~ wc -l /etc/group
>>> 83 /etc/group
>>
>>83 vs. 87, still not the right number.
>>
>>> Not really sure how many groups I'm a member of (in another tool), but 
>>> seems about right.

>>Anyway, how was the results after these manipulations?

> Performance now is good - as long as the cygserver is running.
> With:
>>cmd /v:on /c "echo !TIME! & C:\cygwin64\bin\mintty.exe /bin/echo "test" & 
>>echo !TIME!"
> 12:13:43.53
> 12:13:43.65 = 0:00.12

> Without:
> C:\Users\dehagart>cmd /v:on /c "echo !TIME! & C:\cygwin64\bin\mintty.exe 
> /bin/echo "test" & echo !TIME!"
> 12:14:36.28
> 12:16:24.85 = 1:48.57

Thank you. Not the results I was hoping for, but thank you anyway.
Please continue investigation with Corinna.
And be sure your help is much appreciated :)


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 18.02.2015, <16:40>

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

Re: ssh-host-config script sends /etc/passwd thru awk

[Corinna Vinschen]

On Feb 18 16:35, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> >> > It's a bit confusing to talk about the Cygwin version when this is
> >> > only about openssh and the csih package.  I'm really busy with other
> >> > stuff right now.  I quickly scanned the ssh-*-config scripts again
> >> > and they never write a passwd entry so, if anything, it's a problem
> >> > in the csih helper script.  Does anybody want to inspect
> >> > /usr/share/csih/cygwin-service-installation-helper.sh for this?
> >> 
> >> I'm on it, and the only place, where awk is ever called so far in relation 
> >> to
> >> these files is csih_use_file_etc
> >> 
> >> So far it seems the user need to upgrade or reinstall his openssh package.
> >> I'm off to try and set openssh on my newest VM, that have Cygwin first
> >> installed after 1.7.34 release.
> >> I'll be back.
> 
> > Looking forward to it.
> 
> You were right, the offender is the ssh-user-config, the check_user_homedir()
> function.

...which is using `getent passwd ...', not checking /etc/passwd directly.

> The openssh is the 64-bit version, as in the stackexchange user's case.
> The issue is interesting, though. When I first installed the openssh, it
> offered me "prev" version of the package, even though I was installing from
> the net. Re-running the installer picked the "current" version.
> Setup.exe glitch?

No idea.  Mirror problem?  I never encountered the problem myself.


Corinna

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


pgpcgqwlwrqeN.pgp
Description: PGP signature

Re: ssh-host-config script sends /etc/passwd thru awk

[Frank Fesevur]

2015-02-18 15:00 GMT+01:00 Corinna Vinschen:
> > The openssh is the 64-bit version, as in the stackexchange user's case.
> > The issue is interesting, though. When I first installed the openssh, it
> > offered me "prev" version of the package, even though I was installing from
> > the net. Re-running the installer picked the "current" version.
> > Setup.exe glitch?
>
> No idea.  Mirror problem?  I never encountered the problem myself.

Seen this behavior as well last week, when I installed a new package.
But didn't take real notice until I read this thread.

At this moment I don't have cvs2svn installed. When I select it in
setup it will show 2.3.0-1, which is mentioned as [prev] in the
downloaded setup.ini. When I click it again it will select 2.4.0-1,
the current version in setup.ini

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

Re: ssh-host-config script sends /etc/passwd thru awk

[Corinna Vinschen]

On Feb 18 15:14, Frank Fesevur wrote:
> 2015-02-18 15:00 GMT+01:00 Corinna Vinschen:
> > > The openssh is the 64-bit version, as in the stackexchange user's case.
> > > The issue is interesting, though. When I first installed the openssh, it
> > > offered me "prev" version of the package, even though I was installing 
> > > from
> > > the net. Re-running the installer picked the "current" version.
> > > Setup.exe glitch?
> >
> > No idea.  Mirror problem?  I never encountered the problem myself.
> 
> Seen this behavior as well last week, when I installed a new package.
> But didn't take real notice until I read this thread.
> 
> At this moment I don't have cvs2svn installed. When I select it in
> setup it will show 2.3.0-1, which is mentioned as [prev] in the
> downloaded setup.ini. When I click it again it will select 2.4.0-1,
> the current version in setup.ini

Oh *that*!  I misunderstood Andrey.  Yes, I can reproduce this as well.
This is a result of the changed mechanism to switch through the available
and installed versions.  The idea was to switch through the package
versions in order, with "Uninstall"/"Reinstall"/"Keep"/"Skip" at logical
places.  It didn't occur to me that this results in stepping from "Skip"
to "prev".  Hmm.  This needs fixing I guess...


Thanks,
Corinna

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


pgp_NnoD5ZC5i.pgp
Description: PGP signature

Re: ssh-host-config script sends /etc/passwd thru awk

[Andrey Repin]

Greetings, Corinna Vinschen!

> On Feb 18 16:35, Andrey Repin wrote:
>> Greetings, Corinna Vinschen!
>> >> > It's a bit confusing to talk about the Cygwin version when this is
>> >> > only about openssh and the csih package.  I'm really busy with other
>> >> > stuff right now.  I quickly scanned the ssh-*-config scripts again
>> >> > and they never write a passwd entry so, if anything, it's a problem
>> >> > in the csih helper script.  Does anybody want to inspect
>> >> > /usr/share/csih/cygwin-service-installation-helper.sh for this?
>> >> 
>> >> I'm on it, and the only place, where awk is ever called so far in 
>> >> relation to
>> >> these files is csih_use_file_etc
>> >> 
>> >> So far it seems the user need to upgrade or reinstall his openssh package.
>> >> I'm off to try and set openssh on my newest VM, that have Cygwin first
>> >> installed after 1.7.34 release.
>> >> I'll be back.
>> 
>> > Looking forward to it.
>> 
>> You were right, the offender is the ssh-user-config, the check_user_homedir()
>> function.

> ...which is using `getent passwd ...', not checking /etc/passwd directly.

>> The openssh is the 64-bit version, as in the stackexchange user's case.
>> The issue is interesting, though. When I first installed the openssh, it
>> offered me "prev" version of the package, even though I was installing from
>> the net. Re-running the installer picked the "current" version.
>> Setup.exe glitch?

> No idea.  Mirror problem?  I never encountered the problem myself.

Given the date of last openssh release, not possible.
But I will try scraping current installation and retry anyway.
Thankfully I have fast internet connection. >.> Or two...

Ok, got the results. The first click on the twister selects first available
version of the package. Which is not necessarily "current".
Can easily be reproduced with cygwin-devel package, which have both "prev" and
"test" versions, and is not installed with base install.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 18.02.2015, <17:09>

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

[ATTN Maintainer] netpbm-10.66.02-2

[Achim Gratz]

I can't find the announcement for this package update, plus there seems
to be a packaging bug since pnmtops is missing from both architectures.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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: Setup and perl

[Angelo Graziosi]

Achim Gratz wrote:

Sort of, now that you say itâ the test version of perl does require
perl_base as a dependency, but that requirement also carries to all
other versions unfortunately.  I'll upload an empty package for current.

As for perl_autorebase, it does not matter which version you install and
the perl_autorebase-001001-1 package will be removed soon.


Maybe I am wrong, but things seem a bit strange.

I run setup and choose Exp. In Pending it says that 001001 is currently 
installed and proposes 5.14.4-3. OK I install this 5.14.4-3.


Re-run setup and Curr/Pending re-proposes 001001!

But was setup patched so that when a TEST (Exp) package was installed, 
the next time it does not re-propose the Current? or this works only for 
Cygwin TEST/Curr?



Ciao,
Angelo.

--
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: Setup and perl

[Corinna Vinschen]

On Feb 18 16:01, Angelo Graziosi wrote:
> Achim Gratz wrote:
> >Sort of, now that you say itâ the test version of perl does require
> >perl_base as a dependency, but that requirement also carries to all
> >other versions unfortunately.  I'll upload an empty package for current.
> >
> >As for perl_autorebase, it does not matter which version you install and
> >the perl_autorebase-001001-1 package will be removed soon.
> 
> Maybe I am wrong, but things seem a bit strange.
> 
> I run setup and choose Exp. In Pending it says that 001001 is currently
> installed and proposes 5.14.4-3. OK I install this 5.14.4-3.
> 
> Re-run setup and Curr/Pending re-proposes 001001!

Because 001001 is a bigger version number than 5.14.whatever.  The
mechanism is based on version numbers and if "Curr" is bigger than
"Test", then "Curr" will be chosen unless you explicitely check the
"Exp" check box.

Achim, can you please remove the 001001 version?  The new mechanism
requires a much stricter adherence to ascending version numbers.


Corinna

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


pgpKRSwlhUz42.pgp
Description: PGP signature

Re: Setup and perl

[Angelo Graziosi]

Corinna Vinschen wrote:

Because 001001 is a bigger version number than 5.14.whatever.


Ah, now I remember! I did read it but for some reason I lost it...

Sorry for the noise...

Ciao,
 Angelo.

--
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: setup.exe (Release 2.870)

[Corinna Vinschen]

Hi folks,

A new version of Setup, release 2.870, has been uploaded to

  https://cygwin.com/setup-x86.exe (32 bit version)
  https://cygwin.com/setup-x86_64.exe  (64 bit version)

Changes compared to 2.867:

- Fixing the problem described in
  https://cygwin.com/ml/cygwin/2015-02/msg00563.html and wailed about
  in https://cygwin.com/ml/cygwin/2015-02/msg00564.html.

  It's now supposed to work like that:
  
  The first time you click on an not yet installed package, it chooses
  the "curr" version or, if you selected the "Exp" button, the "test"
  version if there is one.

  When you click further on the package version, it will iterate in
  the order of the package versions:

Skip -> curr -> test -> Skip -> prev -> curr -> test -> ...

- First version cut from the new git repository.


Please send bug reports, as usual, to the public mailing list
cygwin AT cygwin DOT com.


Have fun,
Corinna

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

--
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: setup.exe (Release 2.870)

[Andrey Repin]

Greetings, Corinna Vinschen!

> A new version of Setup, release 2.870, has been uploaded to

>   https://cygwin.com/setup-x86.exe (32 bit version)
>   https://cygwin.com/setup-x86_64.exe  (64 bit version)

> Changes compared to 2.867:

> - Fixing the problem described in
>   https://cygwin.com/ml/cygwin/2015-02/msg00563.html and wailed about
>   in https://cygwin.com/ml/cygwin/2015-02/msg00564.html.

>   It's now supposed to work like that:
>   
>   The first time you click on an not yet installed package, it chooses
>   the "curr" version or, if you selected the "Exp" button, the "test"
>   version if there is one.

>   When you click further on the package version, it will iterate in
>   the order of the package versions:

> Skip -> curr -> test -> Skip -> prev -> curr -> test -> ...

> - First version cut from the new git repository.

Seems all right from here. Thanks for fixing it!


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 18.02.2015, <21:19>

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

Re: Setup and perl

[Achim Gratz]

Corinna Vinschen writes:
> Achim, can you please remove the 001001 version?  The new mechanism
> requires a much stricter adherence to ascending version numbers.

Done.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

--
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 package: pdftk-2.02-1

[Buchbinder, Barry (NIH/NIAID) [E]]

There is no 64 bit pdftk package.  Is that an oversight?

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

--
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: setup.exe (Release 2.870)

[Corinna Vinschen]

On Feb 18 21:19, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> > A new version of Setup, release 2.870, has been uploaded to
> 
> >   https://cygwin.com/setup-x86.exe (32 bit version)
> >   https://cygwin.com/setup-x86_64.exe  (64 bit version)
> 
> > Changes compared to 2.867:
> 
> > - Fixing the problem described in
> >   https://cygwin.com/ml/cygwin/2015-02/msg00563.html and wailed about
> >   in https://cygwin.com/ml/cygwin/2015-02/msg00564.html.
> 
> >   It's now supposed to work like that:
> >   
> >   The first time you click on an not yet installed package, it chooses
> >   the "curr" version or, if you selected the "Exp" button, the "test"
> >   version if there is one.
> 
> >   When you click further on the package version, it will iterate in
> >   the order of the package versions:
> 
> > Skip -> curr -> test -> Skip -> prev -> curr -> test -> ...
> 
> > - First version cut from the new git repository.
> 
> Seems all right from here. Thanks for fixing it!

Thanks for your feedback!


Corinna

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


pgpGlVT0pa4Xm.pgp
Description: PGP signature

Clearing O_NONBLOCK from a pipe may lose data

[Lasse Collin]

(Please Cc me when replying, I'm not subscribed to the list.)

Hi!

I suspect that there is a bug in Cygwin:

1. Create a pipe with both ends in blocking mode (O_NONBLOCK
   is not set).
2. The writer sets its end to non-blocking mode.
3. The writer writes to the pipe.
4. The writer restores its end of the pipe to blocking mode
   before the reader has read anything from the pipe.
5. The writer closes its end of the pipe.
6. The reader reads from the pipe in blocking mode. The last
   bytes written by the writer never appear at the reader,
   thus data is silently lost.

Omitting the step 4 above makes the problem go away.

A small test case is attached. I have tested it under Cygwin64 that was
installed a few days ago on Windows 7. Usage:

gcc -std=gnu99 -Wall -Wextra writer.c -o writer
gcc -std=gnu99 -Wall -Wextra reader.c -o reader
./writer | ./reader

The reader only gets the first 65536 bytes. The remaining  bytes
are never seen by the reader even though all write() calls succeed at
the writer.

I found this problem because I had heard a rumor that there is something
wrong with xz 5.2.0 on Cygwin. Since the file I/O code had been changed
in 5.2.0, I investigated that first. There also seems to be something
wrong with xz 5.2.0 in threaded mode under Cygwin which needs more
investigation (random pthread_join() failures cause assertion failures
if xz was built with --enable-debug).

-- 
Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode
// gcc -std=gnu99 -Wall -Wextra reader.c -o reader

#include 
#include 
#include 
#include 
#include 
#include 

static void
fail(const char *str)
{
	fprintf(stderr, "R: %s\n", str);
	exit(EXIT_FAILURE);
}

int
main(void)
{
	// It is assumed that stdin is a pipe open for reading.
	//
	// Read 8 KiB at a time.
	static unsigned char buf[8 << 10];

	// Total amount read
	unsigned total = 0;

	for (unsigned i = 0; i < 10; ++i) {
		fprintf(stderr, "R: Sleeping\n");
		sleep(1);

		int amount = read(STDIN_FILENO, buf, sizeof(buf));
		fprintf(stderr, "R: read() returned %d\n", amount);

		if (amount >= 0) {
			total += amount;
			fprintf(stderr, "R: Total amount read is %u\n",
	total);
		}
	}

	if (close(STDIN_FILENO))
		fail("Error closing stdin");

	return EXIT_SUCCESS;
}
// gcc -std=gnu99 -Wall -Wextra writer.c -o writer

#include 
#include 
#include 
#include 
#include 
#include 

static void
fail(const char *str)
{
	fprintf(stderr, "W: %s\n", str);
	exit(EXIT_FAILURE);
}

int
main(void)
{
	// It is assumed that stdout is a pipe open for writing.
	//
	// Set stdout to non-blocking mode.
	int flags = fcntl(STDOUT_FILENO, F_GETFL);
	if (flags == -1)
		fail("Cannot get stdout file status flags");

	if (fcntl(STDOUT_FILENO, F_SETFL, flags | O_NONBLOCK) == -1)
		fail("Setting stdout to non-blocking mode failed");

	// Writing 64 KiB works as expected.
	static unsigned char buf[64 << 10];
	if (write(STDOUT_FILENO, buf, sizeof(buf)) != sizeof(buf))
		fail("The first write() failed");

	fprintf(stderr, "W: Wrote %zu bytes\n", sizeof(buf));

	// Writing more returns successfully but the reader won't see
	// these bytes. The reason appears to be the fcntl() below.
	const unsigned small_size = ;
	if (write(STDOUT_FILENO, buf, small_size) != (ssize_t)small_size)
		fail("The second write() failed");

	fprintf(stderr, "W: Wrote %u bytes\n", small_size);

	// Restore the original file status flags to stdout.
	// For some reason this makes the bytes from the last
	// write() disappear. If this is commented out, all
	// data is visible at the reader.
	if (fcntl(STDOUT_FILENO, F_SETFL, flags) == -1)
		fail("Restoring stdout file status flags failed");

	if (close(STDOUT_FILENO))
		fail("Error closing stdout");

	return EXIT_SUCCESS;
}

--
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: slow startup after upgrade

[Roger Orr]

> > and also it no longer opens 14
> > TCP/IP sessions to various ldap servers around the planet (!)
>
> Uh, that might be the result of the other changes which don't open an
> LDAP connection to fetch group info.  14 connections probably means,
> you're in 14 groups in other domains than your login domain.

There weren't any other LDAP requests logged (I was testing with the first
patch 1.7.35-0.1 that reduced the time for running "echo.exe" from 120s to
4.5s) so I don't think it was related to another query.  I may be able to
test this out again tomorrow and get the call stacks of the connect calss.

Incidentally how can you tell the patch level of cygwin1.dll -- the DLL
versions all seem to be 1007.35.0.0 ?

Regards,
Roger.


--
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: fcgi-2.4.0-3

[Ken Brown]

The following packages have been updated in the Cygwin distribution:

* fcgi-2.4.0-3
* libfcgi0-2.4.0-3
* libfcgi-devel-2.4.0-3

FastCGI is a fast, open, and secure Web server interface that solves the 
performance problems inherent in CGI, without introducing the overhead and 
complexity of proprietary APIs.


For 64-bit Cygwin this is the first release of fcgi.  For 32-bit Cygwin this is 
just a rebuild of 2.4.0-2 with gcc 4.9.2-2.


Ken Brown
Cygwin's new fcgi maintainer

--
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: slow startup after upgrade

[Marco Atzeri]

On 2/18/2015 11:01 PM, Roger Orr wrote:



Incidentally how can you tell the patch level of cygwin1.dll -- the DLL
versions all seem to be 1007.35.0.0 ?


uname -a


--
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: netpbm-10.66.02-3

[Yaakov Selkowitz]

The following packages have been updated in the Cygwin distribution:

* netpbm-10.66.02-3
* libnetpbm10-10.66.02-3
* libnetpbm-devel-10.66.02-3

Netpbm is a toolkit for manipulation of graphic images, including
conversion of images between a variety of different formats.  There are
over 220 separate tools in the package including converters for about
100 graphics formats.

This release includes the latest patchset from Fedora and re-enables the
build of pnmtops.

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

[ANNOUNCEMENT] Updated: mscgen-0.20-2

[David Stacey]

The following package has been updated in the Cygwin distribution:

* mscgen-0.20-2

Mscgen is a small programme that parses Message Sequence Chart
descriptions and produces PNG, SVG, EPS or server side image maps
(ismaps) as the output.

This release has been built with libgd3 and three patches from Fedora.

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

[ANNOUNCEMENT] Updated: steghide 0.5.1-3 -- A steganography hiding tool

[Jari Aalto]

PACKAGE DESCRIPTION
===

Homepage: http://steghide.sourceforge.net
License : GPL-2+

A steganography program which hides bits of a data file in some of the
least significant bits of another file in such a way that the
existence of the data file is not visible and cannot be proven.
Steghide is designed to be portable and configurable and features
hiding data in bmp, wav and au files, blowfish encryption, MD5 hashing
of passphrases to blowfish keys, and pseudo-random distribution of
hidden bits in the container data.

CHANGES SINCE LAST RELEASE
==

See homepage.

INSTALL OR UPGRADE NOTES


Cygwin: compiled with libjpeg8
Standard install.

CYGWIN INSTALLATION INFORMATION
===

To install this package, click on the "Install Cygwin now" link on the
 web page. This downloads setup.exe to your
system. Then, run setup and answer all of the questions. You'll find
the package listed in the "All" category. After installation, read the
documentation at directories:

/usr/share/doc//*
/usr/share/doc/Cygwin/.README

If you have questions or comments, please send them to the Cygwin
mailing list at .

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


This message has been sent to cygwin-announce list.

If you want to unsubscribe from the 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

More information on unsubscribing can be found:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at the above URL.

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

Is db_home: windows exactly equivalent to db_home: /%H?

[Warren Young]

I was just scanning through the ntsec page, and saw that the “windows” scheme 
does the same thing as /%H.  I tried it, and it seems to be true.

Is there some minor difference?
--
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