[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

Hi Cygwin friends and users,


I just released a TEST version of the next upcoming Cygwin release,
1.7.33-0.1.

If you want to help testing this new release (which I seriously hope
for), you can find it in your setup-x86.exe or setup-x86_64.exe as
"test" release.


The major change in this new release is the new method to read account
(passwd and group) information from the Windows user databases directly,
without the requirement to generate /etc/passwd and /etc/group files to
generate Unix-like uid and gid.

For your convenience I wrote new documentation.  Since this is a TEST
prerelease, the new documentation is not part of the official docs yet.
Rather have a look at

  https://cygwin.com/preliminary-ntsec.html

If you read it
(which I seriously hope for) and it's all just incomprehensible
gobbledygook to you, please say so on the mailing list

  cygwin AT cygwin DOT com

so we have a chance to improve the documentation.

Please give this TEST release a try.

If you find problems in the new features or regressions compared to the
current stable release 1.7.32, please report them to the public mailing
list

  cygwin AT cygwin DOT com


Following is a list of changes in this new release:


What's new:
-----------

- Cygwin can now generate passwd/group entries directly from Windows
  user databases (local SAM or Active Directory), thus allowing to run
  Cygwin without having to create /etc/passwd and /etc/group files.
  Introduce /etc/nsswitch.conf file to configure passwd/group handling.

  For bordercase which require to use /etc/passwd and /etc/group files,
  change mkpasswd/mkgroup to generate passwd/group entries compatible
  with the entries read from SAM/AD.

- /proc/cygdrive is a new symlink pointing to the current cygdrive prefix.
  This can be utilized in scripts to access paths via cygdrive prefix, even
  if the cygdrive prefix has been changed by the user.

- /proc/partitions now prints the windows mount points the device is mounted
  on.  This allows to recognize the underlying Windows devices of the Cygwin
  raw device names.

- New API: quotactl, designed after the Linux/BSD function, but severly
  restricted:  Windows only supports user block quotas on NTFS, no group
  quotas, no inode quotas, no time constraints.

- New APIs: ffsl, ffsll (glibc extensions).


What changed:
-------------

- New internal exception handling based on SEH on 64 bit Cygwin.

- Revamp Solaris ACL implementation to more closely work like POSIX ACLs
  are supposed to work.  Finally implement a CLASS_OBJ emulation.  Update
  getfacl(1)/setfacl(1) accordingly.

- Drop the current working directory from the default DLL search path in
  favor of Cygwin's /bin dir.

- Improve various header files for C++- and standards-compliance.

- Doug Lea malloc implementation update from 2.8.3 to the latest 2.8.6.


Bug Fixes
---------

- Per POSIX, dirfd(3) now returns EINVAL rather than EBADF on invalid
  directory stream.

- Fix a resource leak in rmdir(2).

- Fix fchmod(2)/fchown(2)/fsetxattr(2) in case the file got renamed after
  open and before calling one of the affected functions.
  Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00517.html

- Handle Netapp-specific problem in statvfs(2)/fstatvfs(2).
  Addresses: https://cygwin.com/ml/cygwin/2014-06/msg00425.html

- Fix chown(2) on ptys in a corner case.

- Generate correct error when a path is inaccessible due to missing permissions.
  Addresses: https://cygwin.com/ml/cygwin-developers/2014-10/msg00010.html

- Don't hang in accept calls if socket is no listener.  Set errno to EINVAL
  instead.  Don't hang in read/recv/recvfrom/recvmsg calls if socket is
  connection oriented and not connected.  Set errno to ENOTCONN instead.

- Don't allow seeking on serial lines and sockets.  Set errno to ESPIPE
  instead.
  Addresses: https://cygwin.com/ml/cygwin/2014-08/msg00319.html

- Fix output of /proc/<PID>/statm.

- Fix a SEGV in cygcheck if the environment variable COMSPEC is not, or
  incorrectly set.
  Addresses: https://cygwin.com/ml/cygwin/2014-10/msg00292.html


To install 32-bit Cygwin use http://cygwin.com/setup-x86.exe
To install 64 bit Cygwin use http://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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Habermann, Dave (DA)]

Read through https://cygwin.com/preliminary-ntsec.html and in general found it to be quite useful.  I'm hoping to do some testing perhaps later this week or early next.  I have a couple of questions:

1) Any thoughts about the rough timing of this "going live"?

2) The documentation says (as I read it): Well-known/builtin accounts named as in Windows, then (for domain member) "Local machine accounts of a domain member machine get a Cygwin user name the same way as accounts from another domain: The local machine name gets prepended".  As I read this, cyg_serv account (under which I currently run SSHD) would now have a new name MYMACHINE+cyg_serv.  Am I reading this correctly?  Is there some reconfiguration I'll need to do to get SSHD to run properly?

3) I also read "Cygwin implements the Solaris API to access Windows ACLs in a Unixy way" (although your email says "Revamp Solaris ACL implementation to more closely work like POSIX ACLs are supposed to work").  So is it Solaris or is it POSIX, and if Solaris then I wonder why since it seems that everywhere else you've tried to be as POSIX as possible.

Thanks for all your hard work on this, I will certainly be one of the benefactors (12 Mb group file, takes hours to refresh so not done since this time last year).

Dave

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2762 bytes --]

On Oct 22 13:35, Habermann, Dave (DA) wrote:
> Read through https://cygwin.com/preliminary-ntsec.html and in general
> found it to be quite useful.  I'm hoping to do some testing perhaps
> later this week or early next.  I have a couple of questions:
> 
> 1) Any thoughts about the rough timing of this "going live"?

I'm heading for "at some arbitrary day in November".

> 2) The documentation says (as I read it): Well-known/builtin accounts
> named as in Windows, then (for domain member) "Local machine accounts
> of a domain member machine get a Cygwin user name the same way as
> accounts from another domain: The local machine name gets prepended".
> As I read this, cyg_serv account (under which I currently run SSHD)
> would now have a new name MYMACHINE+cyg_serv.  Am I reading this
> correctly?  Is there some reconfiguration I'll need to do to get SSHD
> to run properly?

In theory, no.  The last OpenSSH update, 6.7p1-1, alreadyd contained
the upstream fix to work with local sshd accounts which have the
machine name prepended.

> 3) I also read "Cygwin implements the Solaris API to access Windows
> ACLs in a Unixy way" (although your email says "Revamp Solaris ACL
> implementation to more closely work like POSIX ACLs are supposed to
> work").  So is it Solaris or is it POSIX, and if Solaris then I wonder
> why since it seems that everywhere else you've tried to be as POSIX as
> possible.

Solaris ACLs *are* POSIX ACLs :)

The difference is not how these ACLs look like, but only in the API
used to access the ACLs.

The Solaris API was finished and working at the time I implemented this
POSIX ACL support in Cygwin, while the POSIX draft 1003.1e was still in
the works, and our role model Linux didn't even now how to spell ACL.
These days, Linux implements the POSIX 1003.1e draft, (which, funny
enough, has been withdrawn long ago), while Solaris and Cygwin provide
the original Solaris API.

What has chnaged with 1.7.33 is that the handling of POSIX ACLs is
now much more aligned with how they are implemented on Solaris or 
Linux.  Especially the CLASS_OBJ stuff didn't exist before, but now
it gets emulated.

> Thanks for all your hard work on this, I will certainly be one of the
> benefactors (12 Mb group file, takes hours to refresh so not done
> since this time last year).

Cool, thank you!

I'm really looking forward to this release.  The account handling
changes is something I had on the TODO list for ages, and the new
SEH-based internal exception handling is a great benefit for the 64 bit
version.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

On Oct 22 15:54, Corinna Vinschen wrote:
> On Oct 22 13:35, Habermann, Dave (DA) wrote:
> > 3) I also read "Cygwin implements the Solaris API to access Windows
> > ACLs in a Unixy way" (although your email says "Revamp Solaris ACL
> > implementation to more closely work like POSIX ACLs are supposed to
> > work").  So is it Solaris or is it POSIX, and if Solaris then I wonder
> > why since it seems that everywhere else you've tried to be as POSIX as
> > possible.
> 
> Solaris ACLs *are* POSIX ACLs :)
> 
> The difference is not how these ACLs look like, but only in the API
> used to access the ACLs.
> 
> The Solaris API was finished and working at the time I implemented this
> POSIX ACL support in Cygwin, while the POSIX draft 1003.1e was still in
> the works, and our role model Linux didn't even now how to spell ACL.
> These days, Linux implements the POSIX 1003.1e draft, (which, funny
> enough, has been withdrawn long ago), while Solaris and Cygwin provide
> the original Solaris API.

Btw., this probably goes without saying, but I would be really grateful
if somebody wants to take a stab at implementing the POSIX API, maybe
just on top of the underlying Solaris API, maybe as separate libacl.a
as on Linux.


One may dream...
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Achim Gratz]

Corinna Vinschen writes:
> In theory, no.  The last OpenSSH update, 6.7p1-1, alreadyd contained
> the upstream fix to work with local sshd accounts which have the
> machine name prepended.

I will check this tomorrow, I somehow missed that this patch was live.
The entry for sshd was the only thing still in my servers' /etc/passwd.


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

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

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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Achim Gratz]

Achim Gratz writes:
> Corinna Vinschen writes:
>> In theory, no.  The last OpenSSH update, 6.7p1-1, alreadyd contained
>> the upstream fix to work with local sshd accounts which have the
>> machine name prepended.
>
> I will check this tomorrow, I somehow missed that this patch was live.
> The entry for sshd was the only thing still in my servers' /etc/passwd.

I can confirm that with this OpenSSH version I don't need the workaround
via /etc/passwd anymore.


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

SD adaptation for Waldorf microQ V2.22R2:
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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

On Oct 23 20:01, Achim Gratz wrote:
> Achim Gratz writes:
> > Corinna Vinschen writes:
> >> In theory, no.  The last OpenSSH update, 6.7p1-1, alreadyd contained
> >> the upstream fix to work with local sshd accounts which have the
> >> machine name prepended.
> >
> > I will check this tomorrow, I somehow missed that this patch was live.
> > The entry for sshd was the only thing still in my servers' /etc/passwd.
> 
> I can confirm that with this OpenSSH version I don't need the workaround
> via /etc/passwd anymore.

Thanks for testing this feature!


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Habermann, Dave (DA)]

Loaded the test release here today and found that it seems to work as expected, both without the /etc/nsswitch.conf file (operates as before) and with both passwd and group set to "db" in the file.  Only two slightly negative observations I've made so far are 1) ps -ef only allows for 8 character UIDs, and thus longer UIDs (for example MyMachine+cyg_server) don't show up well and 2) the very first cygwin process I start seems to take a bit longer to start up now (in either mode) than before (7-10 seconds depending on the contents of nsswitch).  Perhaps this is possibly due to the fact that I'm accessing AD at some distance over a VPN?  However, the SECOND process and all subsequent ones seem to start significantly faster than before (THANKS FOR THAT!).

Question:  In the documentation you indicate that "If cygserver is running it will provide passwd and group entry caching for all processes in every Cygwin process tree started after cygserver."  Normally I have several processes (specifically sshd, cygserver, cron and httpd2) automatically start up as services when my system boots up, and I have not specified the order.  Would it now be desirable to have cygserver starting up first, followed by the others?  If so, what would be the preferred way to create such a dependency/startup timing?  Would a service dependency be sufficient?

Thanks again for your efforts on this!

Dave

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]

On Oct 27 18:35, Habermann, Dave (DA) wrote:
> Loaded the test release here today and found that it seems to work as
> expected, both without the /etc/nsswitch.conf file (operates as
> before) and with both passwd and group set to "db" in the file.  Only
> two slightly negative observations I've made so far are 1) ps -ef only
> allows for 8 character UIDs, and thus longer UIDs (for example
> MyMachine+cyg_server) don't show up well

This was already a problem for some time.  I have a look into fixing this.

> and 2) the very first cygwin
> process I start seems to take a bit longer to start up now (in either
> mode) than before (7-10 seconds depending on the contents of
> nsswitch).  Perhaps this is possibly due to the fact that I'm
> accessing AD at some distance over a VPN?

This is very likely.  For this scenario it might make a lot of sense
to run cygserver, see the docs for this.

> However, the SECOND process
> and all subsequent ones seem to start significantly faster than before
> (THANKS FOR THAT!).

You're welcome :)

> Question:  In the documentation you indicate that "If cygserver is
> running it will provide passwd and group entry caching for all
> processes in every Cygwin process tree started after cygserver."
> Normally I have several processes (specifically sshd, cygserver, cron
> and httpd2) automatically start up as services when my system boots
> up, and I have not specified the order.  Would it now be desirable to
> have cygserver starting up first, followed by the others?  If so, what
> would be the preferred way to create such a dependency/startup timing?
> Would a service dependency be sufficient?

Now that you mention it... yes, a service dependency might be helpful.
Unfortunately it's tricky to automate this.  Is it possible to add
service deps after having installed a service?

> Thanks again for your efforts on this!

I'm glad if you like it,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Habermann, Dave (DA)]

-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of Corinna Vinschen
Sent: Monday, October 27, 2014 5:27 PM
To: cygwin@cygwin.com
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

On Oct 27 18:35, Habermann, Dave (DA) wrote:

>> Question:  In the documentation you indicate that "If cygserver is
>> running it will provide passwd and group entry caching for all
>> processes in every Cygwin process tree started after cygserver."
>> Normally I have several processes (specifically sshd, cygserver, cron
>> and httpd2) automatically start up as services when my system boots
>> up, and I have not specified the order.  Would it now be desirable to
>> have cygserver starting up first, followed by the others?  If so, what
>> would be the preferred way to create such a dependency/startup timing?
>> Would a service dependency be sufficient?

>Now that you mention it... yes, a service dependency might be helpful.
>Unfortunately it's tricky to automate this.  Is it possible to add
>service deps after having installed a service?

According to http://serverfault.com/questions/24821/how-to-add-dependency-on-a-windows-service-after-the-service-is-installed it is possible to add a dependency to an already existing service.  I agree it would be hard to automate in the install scripts, as one would have to either ask the user about their intent to run other services or rely that they configured cygserver first and then check to see if it has been already configured to determine if a dependency should be created.  I would think that some instructions in the docs near the statement mentioned above would be more than sufficient, since this is a "fine tuning" sort of thing.

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]

On Oct 28 13:41, Habermann, Dave (DA) wrote:
> 
> 
> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of Corinna Vinschen
> Sent: Monday, October 27, 2014 5:27 PM
> To: cygwin@cygwin.com
> Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1
> 
> On Oct 27 18:35, Habermann, Dave (DA) wrote:
> 
> >> Question:  In the documentation you indicate that "If cygserver is
> >> running it will provide passwd and group entry caching for all
> >> processes in every Cygwin process tree started after cygserver."
> >> Normally I have several processes (specifically sshd, cygserver, cron
> >> and httpd2) automatically start up as services when my system boots
> >> up, and I have not specified the order.  Would it now be desirable to
> >> have cygserver starting up first, followed by the others?  If so, what
> >> would be the preferred way to create such a dependency/startup timing?
> >> Would a service dependency be sufficient?
> 
> >Now that you mention it... yes, a service dependency might be helpful.
> >Unfortunately it's tricky to automate this.  Is it possible to add
> >service deps after having installed a service?
> 
> According to
> http://serverfault.com/questions/24821/how-to-add-dependency-on-a-windows-service-after-the-service-is-installed
> it is possible to add a dependency to an already existing service.  I
> agree it would be hard to automate in the install scripts, as one
> would have to either ask the user about their intent to run other
> services or rely that they configured cygserver first and then check
> to see if it has been already configured to determine if a dependency
> should be created.  I would think that some instructions in the docs
> near the statement mentioned above would be more than sufficient,
> since this is a "fine tuning" sort of thing.

Agreed.  Do you have some idea how to phrase this?  I'd be grateful
for a nice two or three paragraphs discussing this.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]

On 10/28/2014 08:20 AM, Corinna Vinschen wrote:
>>> Now that you mention it... yes, a service dependency might be helpful.
>>> Unfortunately it's tricky to automate this.  Is it possible to add
>>> service deps after having installed a service?
>>
>> According to
>> http://serverfault.com/questions/24821/how-to-add-dependency-on-a-windows-service-after-the-service-is-installed
>> it is possible to add a dependency to an already existing service.  I
>> agree it would be hard to automate in the install scripts, as one
>> would have to either ask the user about their intent to run other
>> services or rely that they configured cygserver first and then check
>> to see if it has been already configured to determine if a dependency
>> should be created.  I would think that some instructions in the docs
>> near the statement mentioned above would be more than sufficient,
>> since this is a "fine tuning" sort of thing.
> 
> Agreed.  Do you have some idea how to phrase this?  I'd be grateful
> for a nice two or three paragraphs discussing this.

On Linux, systemd has a notion of soft dependencies, where any service
can do a one-sided advertisement that "if this other service is also
installed, then here is the order that must be observed between bringing
the two services up; but there is no requirement that the other service
be installed".  Note in particular that both 'before' and 'after' soft
dependencies can be specified.  I wonder if cygserver could be taught to
do something similar - but it would probably be a lot of work.
cygserver would have to maintain some sort of database of requested
dependencies, and then when installing a service, it would check both if
the current service has any soft dependency on other installed cygserver
services, as well as whether any other installed cygserver service has a
soft dependency on the service being installed, and in either case, add
a Windows hard dependency on the correct service.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2495 bytes --]

On Oct 28 08:58, Eric Blake wrote:
> On 10/28/2014 08:20 AM, Corinna Vinschen wrote:
> >>> Now that you mention it... yes, a service dependency might be helpful.
> >>> Unfortunately it's tricky to automate this.  Is it possible to add
> >>> service deps after having installed a service?
> >>
> >> According to
> >> http://serverfault.com/questions/24821/how-to-add-dependency-on-a-windows-service-after-the-service-is-installed
> >> it is possible to add a dependency to an already existing service.  I
> >> agree it would be hard to automate in the install scripts, as one
> >> would have to either ask the user about their intent to run other
> >> services or rely that they configured cygserver first and then check
> >> to see if it has been already configured to determine if a dependency
> >> should be created.  I would think that some instructions in the docs
> >> near the statement mentioned above would be more than sufficient,
> >> since this is a "fine tuning" sort of thing.
> > 
> > Agreed.  Do you have some idea how to phrase this?  I'd be grateful
> > for a nice two or three paragraphs discussing this.
> 
> On Linux, systemd has a notion of soft dependencies, where any service
> can do a one-sided advertisement that "if this other service is also
> installed, then here is the order that must be observed between bringing
> the two services up; but there is no requirement that the other service
> be installed".  Note in particular that both 'before' and 'after' soft
> dependencies can be specified.  I wonder if cygserver could be taught to
> do something similar - but it would probably be a lot of work.

There's a twist here.  The activity, whether or not to ask cygserver, is
not controlled by cygserver.  The decision is made in the first process
of a Cygwin process tree, and then if any other process fails to contact
cygserver,

One idea to workaround would be to check for Session 0, the session
in which the service processes run.  If a process fails to contact
cygserver, it checks if it's running in session 0.  If so, it will
try to contact cygserver again later.

Potential downside: This might slowdown account handling again, but
AFAIK, trying to open a non-existing named pipe (used to communicate
between process and cygserver) is blazingly fast.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Habermann, Dave (DA)]

>> should be created.  I would think that some instructions in the docs
>> near the statement mentioned above would be more than sufficient,
>> since this is a "fine tuning" sort of thing.

> Agreed.  Do you have some idea how to phrase this?  I'd be grateful
> for a nice two or three paragraphs discussing this.

Will do, but it will take me a bit as I'd like to make sure I've got 
it right, plus I've got some "day job interference" for the next day
or so.

RE: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Habermann, Dave (DA)]

>> should be created.  I would think that some instructions in the docs
>> near the statement mentioned above would be more than sufficient,
>> since this is a "fine tuning" sort of thing.

> Agreed.  Do you have some idea how to phrase this?  I'd be grateful
> for a nice two or three paragraphs discussing this.

Have a look...don't hesitate to re-work if my phrasing doesn't fit....

<!--context section-->
The advantage of cygserver caching is that it's system-wide and, as long as cygserver is running, unforgetful. Every Cygwin process on the system will have the cygserver cache at its service. Additionally, all information requested from cygserver once, will be cached inside the process itself and, again, propagated to child processes.

<!--insertion starts here->
If you automatically start cygwin processes as windows services at system startup, you may wish to consider starting cygserver first in order to take advantage of this system-wide caching.  To assure that cygserver has started prior to starting sshd or other cygwin processes, you may wish to create service startup dependencies.  Cygserver should probably wait for Windows TCPIP and AFD services before it starts, and then other cygwin process should start after cygserver.  Example windows commands to accomplish this (after the services already exist) are shown below.  You will need an administrative prompt to run the sc config commands.

# Delay Cygserver until TCPIP and AFD have started
# Note the (odd) required space character after "depend="

sc config cygserver depend= tcp/afd

# Delay sshd until after Cygserver has started
# Again note the (odd) required space character after "depend="

sc config sshd depend= cygserver

# View the Cygserver service details

sc qc cygserver

Note that this "sc config" command REPLACES any existing dependencies.  The above changes will not impact the running instance, only future instances.

# To remove all dependencies from the cygserver service

sc config cygserver depend= /

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

On Oct 28 20:22, Habermann, Dave (DA) wrote:
> >> should be created.  I would think that some instructions in the docs
> >> near the statement mentioned above would be more than sufficient,
> >> since this is a "fine tuning" sort of thing.
> 
> > Agreed.  Do you have some idea how to phrase this?  I'd be grateful
> > for a nice two or three paragraphs discussing this.
> 
> Have a look...don't hesitate to re-work if my phrasing doesn't fit....
> [...]

Excellent, thank you very much!  I used it almost verbatim and just
added the XML markup.  If you want to take a look, I uploaded it to
the preliminary docs at

  https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-caching


Thanks again,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[David Rothenberger]

Corinna Vinschen wrote:
> On Oct 28 20:22, Habermann, Dave (DA) wrote:
>>>> should be created.  I would think that some instructions in the docs
>>>> near the statement mentioned above would be more than sufficient,
>>>> since this is a "fine tuning" sort of thing.
>>
>>> Agreed.  Do you have some idea how to phrase this?  I'd be grateful
>>> for a nice two or three paragraphs discussing this.
>>
>> Have a look...don't hesitate to re-work if my phrasing doesn't fit....
>> [...]
> 
> Excellent, thank you very much!  I used it almost verbatim and just
> added the XML markup.  If you want to take a look, I uploaded it to
> the preliminary docs at
> 
>   https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-caching

On my Windows 7 machine, the service is tcpip, not tcp. Running

 sc config cygserver depend= tcp/afd

prevents the cygserver service from starting. Using "tcpip/afd" worked
for me.

-- 
David Rothenberger  ----  daveroth@acm.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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

On Oct 30 10:00, David Rothenberger wrote:
> Corinna Vinschen wrote:
> > On Oct 28 20:22, Habermann, Dave (DA) wrote:
> >>>> should be created.  I would think that some instructions in the docs
> >>>> near the statement mentioned above would be more than sufficient,
> >>>> since this is a "fine tuning" sort of thing.
> >>
> >>> Agreed.  Do you have some idea how to phrase this?  I'd be grateful
> >>> for a nice two or three paragraphs discussing this.
> >>
> >> Have a look...don't hesitate to re-work if my phrasing doesn't fit....
> >> [...]
> > 
> > Excellent, thank you very much!  I used it almost verbatim and just
> > added the XML markup.  If you want to take a look, I uploaded it to
> > the preliminary docs at
> > 
> >   https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-caching
> 
> On my Windows 7 machine, the service is tcpip, not tcp. Running
> 
>  sc config cygserver depend= tcp/afd
> 
> prevents the cygserver service from starting. Using "tcpip/afd" worked
> for me.

Typo fixed in CVS.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Andrey Repin]

Greetings, David Rothenberger!

>> On Oct 28 20:22, Habermann, Dave (DA) wrote:
>>>>> should be created.  I would think that some instructions in the docs
>>>>> near the statement mentioned above would be more than sufficient,
>>>>> since this is a "fine tuning" sort of thing.
>>>
>>>> Agreed.  Do you have some idea how to phrase this?  I'd be grateful
>>>> for a nice two or three paragraphs discussing this.
>>>
>>> Have a look...don't hesitate to re-work if my phrasing doesn't fit....
>>> [...]
>> 
>> Excellent, thank you very much!  I used it almost verbatim and just
>> added the XML markup.  If you want to take a look, I uploaded it to
>> the preliminary docs at
>> 
>>   https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-caching

> On my Windows 7 machine, the service is tcpip, not tcp. Running

>  sc config cygserver depend= tcp/afd

TCPIP and AFD are two separate services.

> prevents the cygserver service from starting. Using "tcpip/afd" worked
> for me.



--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 31.10.2014, <2:36>

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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Habermann, David (D)]

>>> On Oct 28 20:22, Habermann, Dave (DA) wrote:

>> On my Windows 7 machine, the service is tcpip, not tcp. Running

>>>  sc config cygserver depend= tcp/afd

>TCPIP and AFD are two separate services.

Yes, but this is the syntax used to identify the two separate services in the SC CONFIG command, and this was a typo....the service is TCPIP

--
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] TEST RELEASE: Cygwin 1.7.33-0.1

[Andrey Repin]

Greetings, Corinna Vinschen!

> Now that you mention it... yes, a service dependency might be helpful.
> Unfortunately it's tricky to automate this.  Is it possible to add
> service deps after having installed a service?

Yes, it is possible. I do it all the time.
Actually, it's as simple as adding REG_MILTI_SZ value to a service key.
The question is, how manageable is this process from cygwin side.
I know we can obtain a list of current Cygwin services. (Those installed
through cygrunsrv.)
Does it make sense to automate addition/removal of cygserver dependency, if
one is [being] installed?


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 29.10.2014, <2:38>

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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Andrey Repin]

Greetings, Habermann, Dave (DA)!

> Loaded the test release here today and found that it seems to work as
> expected, both without the /etc/nsswitch.conf file (operates as before) and
> with both passwd and group set to "db" in the file.  Only two slightly
> negative observations I've made so far are 1) ps -ef only allows for 8
> character UIDs, and thus longer UIDs (for example MyMachine+cyg_server)
> don't show up well and 2) the very first cygwin process I start seems to
> take a bit longer to start up now (in either mode) than before (7-10 seconds
> depending on the contents of nsswitch).  Perhaps this is possibly due to the
> fact that I'm accessing AD at some distance over a VPN?  However, the SECOND
> process and all subsequent ones seem to start significantly faster than before (THANKS FOR THAT!).

If you are using cygserver (from your message, this appears to be the case),
this is expected behavior, given your present conditions.

> Question:  In the documentation you indicate that "If cygserver is running
> it will provide passwd and group entry caching for all processes in every
> Cygwin process tree started after cygserver."  Normally I have several
> processes (specifically sshd, cygserver, cron and httpd2) automatically
> start up as services when my system boots up, and I have not specified the
> order.  Would it now be desirable to have cygserver starting up first,
> followed by the others?

That wouldn't make a change in case of services. Facility provided by
cygserver is optional, and any process that did not succeed to locate
cygserver, will fall back to request the data directly from domain controller.

However, if you have a periodic cron job running fairly often, running
cygserver will likely speed up its startup process. But again, there's no
long-time gains from specifying startup order.

> If so, what would be the preferred way to create such a dependency/startup timing?
> Would a service dependency be sufficient?

Yes. Service dependency will be sufficient, if you find it necessary.
I would also make sure, that cygserver/sshd depends on TCPIP and AFD services.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 27.10.2014, <23:01>

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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Tom Schutter]

On Wed 2014-10-22 11:23, Corinna Vinschen wrote:
> For your convenience I wrote new documentation.  Since this is a TEST
> prerelease, the new documentation is not part of the official docs yet.
> Rather have a look at
> 
>   https://cygwin.com/preliminary-ntsec.html

"machine is no domain member" -> "machine is not a domain member"

-- 
Tom Schutter

--
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] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

On Oct 22 20:57, Tom Schutter wrote:
> On Wed 2014-10-22 11:23, Corinna Vinschen wrote:
> > For your convenience I wrote new documentation.  Since this is a TEST
> > prerelease, the new documentation is not part of the official docs yet.
> > Rather have a look at
> > 
> >   https://cygwin.com/preliminary-ntsec.html
> 
> "machine is no domain member" -> "machine is not a domain member"

Thanks, I applied this as patch.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Luke Kendall]

On 24/10/14 02:43, Corinna Vinschen wrote:
 > On Oct 22 20:57, Tom Schutter wrote:
 >> On Wed 2014-10-22 11:23, Corinna Vinschen wrote:
 >>> For your convenience I wrote new documentation.  Since this is a TEST
 >>> prerelease, the new documentation is not part of the official docs yet.
 >>> Rather have a look at
 >>>
 >>>   https://cygwin.com/preliminary-ntsec.html
 >> "machine is no domain member" -> "machine is not a domain member"
 > Thanks, I applied this as patch.
 >
 >
 > Corinna
 >

Obviously, all the URLs for the section called “Mapping Windows accounts 
to POSIX accounts” will become correct when the file is renamed from 
preliminary-ntsec.html to ntsec.html.  But in the section where you talk 
about the 'problem with the definition of a "correct" ACL which 
disallows mapping of certain POSIX permissions cleanly', previously the 
URL referenced immediately after that text appeared as 'the section 
called "The POSIX permission mapping leak" ', but now it's yet another 
reference to 'the section called “Mapping Windows accounts to POSIX 
accounts”'

-- Is that a mistake?

Other suggestions/notes:

'One of them is that the idea to have always small files is flawed.'
-->
'One of them is that the idea that these files will always be small, is 
flawed.'

'so we rely on some mechanism to convert SIDs to uid/gid values and vice 
versa'
-->
'so we need a mechanism to convert SIDs to uid/gid values and vice versa'

'It allows [us] to generate uid/gid values '

'Read /etc/passwd and /etc/group files [if they exist], just as in the 
olden days'

'If [the passwd or group] files are present, they will be scanned on demand'

'Logon SIDs: The own[huh?  owner's?  user's?] LogonSid is converted'

'if the AD administrators chose an unreasonable[unreasonably] small'

'which keeps an analogue value of the trustPosixOffset'
-->
'which keeps an analog of the trustPosixOffset'

'how do we uniquely differ[distinguish] between them by name?'

'very costly (read: slow) sea[r]ch operations'

(By the way, if you want to belong to multiple groups, is the only way 
to do this via an /etc/group file?  Also, it occurs to me that another 
way to store the unix home dir, etc., would be a 'partial passwd' file 
that omitted the fields for the parts supplied easily by AD (SID, GID)? 
  That's just an idle thought.)

'Cygwin process tree, which[ever?] first process'

'is not running a[t] the time'

'via an undocumented API[,] an applications[application] can fetch'

'When Cygwin stat's[stats, or: stat()s] files'

'If both[,] files and db are specified'
'Cygwin will always try the files first, then the db. '
-- is that because the db will always be more trustworthy than the files?

BTW, the POSIX permission mapping leak used to have a section heading; 
it's now just unmarked, inside the File Permissions section.  (I'm just 
pointing that out.)

Hope this helps!  You've obviously put a lot of thought and effort into 
all this: thanks.

luke


--
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] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 5733 bytes --]

On Oct 24 17:35, Luke Kendall wrote:
> On 24/10/14 02:43, Corinna Vinschen wrote:
> > On Oct 22 20:57, Tom Schutter wrote:
> >> On Wed 2014-10-22 11:23, Corinna Vinschen wrote:
> >>> For your convenience I wrote new documentation.  Since this is a TEST
> >>> prerelease, the new documentation is not part of the official docs yet.
> >>> Rather have a look at
> >>>
> >>>   https://cygwin.com/preliminary-ntsec.html
> >> "machine is no domain member" -> "machine is not a domain member"
> > Thanks, I applied this as patch.
> >
> >
> > Corinna
> >
> 
> Obviously, all the URLs for the section called “Mapping Windows accounts to
> POSIX accounts” will become correct when the file is renamed from
> preliminary-ntsec.html to ntsec.html.  But in the section where you talk
> about the 'problem with the definition of a "correct" ACL which disallows
> mapping of certain POSIX permissions cleanly', previously the URL referenced
> immediately after that text appeared as 'the section called "The POSIX
> permission mapping leak" ', but now it's yet another reference to 'the
> section called “Mapping Windows accounts to POSIX accounts”'
> 
> -- Is that a mistake?

Yes, it is.  Thanks for catching.  It should point to the chapter
"File permissions".

> Other suggestions/notes:
> 
> 'One of them is that the idea to have always small files is flawed.'
> -->
> 'One of them is that the idea that these files will always be small, is
> flawed.'
> 
> 'so we rely on some mechanism to convert SIDs to uid/gid values and vice
> versa'
> -->
> 'so we need a mechanism to convert SIDs to uid/gid values and vice versa'
> 
> 'It allows [us] to generate uid/gid values '
> 
> 'Read /etc/passwd and /etc/group files [if they exist], just as in the olden
> days'
> 
> 'If [the passwd or group] files are present, they will be scanned on demand'
> 
> 'Logon SIDs: The own[huh?  owner's?  user's?] LogonSid is converted'

The logon SID of the current session.  I rephrased this now to:

"Logon SIDs: The LogonSid of the current user's session is converted ..."

> 'if the AD administrators chose an unreasonable[unreasonably] small'
> 
> 'which keeps an analogue value of the trustPosixOffset'
> -->
> 'which keeps an analog of the trustPosixOffset'

British vs. American English... ;)

> 'how do we uniquely differ[distinguish] between them by name?'
> 
> 'very costly (read: slow) sea[r]ch operations'
> 
> (By the way, if you want to belong to multiple groups, is the only way to do
> this via an /etc/group file?

You mean via the gr_mem field?  That's not evaluated anymore.  Group
membership is stored in SAM or AD.

> Also, it occurs to me that another way to
> store the unix home dir, etc., would be a 'partial passwd' file that omitted
> the fields for the parts supplied easily by AD (SID, GID)?  That's just an
> idle thought.)

But that means you have to read the files again.  Thre's not much of an
advantage to having full passwd and group files then for the user, nor
for Cygwin itself.  Plus, you have to implement two different reading
algos per file type.

> 'Cygwin process tree, which[ever?] first process'

Hmm.  Sounds bad, right?  What I'm trying to say is, if the first
process of a process tree found cygserver isn't started, it will not try
to ask cygserver again, and it will propagate the lack of cygserver to
the child processes, so they will neither try to contact cygserver.  If
you have a catchy way to phrase this in less words, I'd be quite happy.

Btw.

In the document I'm talking of the "first process of a Cygwin process
tree" throughout.  Is it clear at all what that means?  For a Cygwin
Terminal session that would be the mintty process.  If you have this:

  Cygwin process 1 starts Cygwin process 2
  Cygwin process 2 starts CMD.EXE
  CMD.EXE starts Cygwin process 3
  Cygwin process 3 starts Cygwin process 4

Then you have two Cygwin process trees with Cygwin process 1 and
Cygwin process 3 being the "first processes in a Cygwin process tree".

Is there a better way to phrase this in English?  Would it make more
sense to use "parent" or "grandparent" for the first process?  Or
any other expression?

> 'is not running a[t] the time'
> 
> 'via an undocumented API[,] an applications[application] can fetch'
> 
> 'When Cygwin stat's[stats, or: stat()s] files'
> 
> 'If both[,] files and db are specified'

There is a comma already.  Or am I looking into the wrong line?

> 'Cygwin will always try the files first, then the db. '
> -- is that because the db will always be more trustworthy than the files?

It's because it doesn't make sense the other way around.  The DBs will
always have a valid reply for an existing account, thus there can't be
any fallback from db to files.

> BTW, the POSIX permission mapping leak used to have a section heading; it's
> now just unmarked, inside the File Permissions section.  (I'm just pointing
> that out.)

That was deliberate.  I was wondering if the lengthy description of a
bordercase in permission handling really deserved its own chapter and
came up with a "no".

> Hope this helps!  You've obviously put a lot of thought and effort into all
> this: thanks.

This really helps a lot, thank you!  I applied a patch in your name,
hope that's ok.  I also uploaded this version to

  https://cygwin.com/preliminary-ntsec.html

If you (or somebody else) have suggestions for the two problems outlined
above, I'd be really grateful.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Luke Kendall]

On 24/10/14 21:37, Corinna Vinschen wrote:
 > On Oct 24 17:35, Luke Kendall wrote:
 >> On 24/10/14 02:43, Corinna Vinschen wrote:
 >>> On Oct 22 20:57, Tom Schutter wrote:
 >>>> On Wed 2014-10-22 11:23, Corinna Vinschen wrote:
 >>>>> For your convenience I wrote new documentation.  Since this is a TEST
[snip]
 >>>>>
 >>>>>
 >>>>> 'Logon SIDs: The own[huh?  owner's?  user's?] LogonSid is converted'
 >
 > The logon SID of the current session.  I rephrased this now to:
 >
 > "Logon SIDs: The LogonSid of the current user's session is converted ..."
 >
That's clear.
 >> 'if the AD administrators chose an unreasonable[unreasonably] small'
 >>
 >> 'which keeps an analogue value of the trustPosixOffset'
 >> -->
 >> 'which keeps an analog of the trustPosixOffset'
 >
 > British vs. American English...
Sure, and I thought you'd prefer the American, but I'm happy to see 
British spelling.  But the main point was to drop the word "value".  "A 
is an analog of B", not an analog /value/ of B.
 >
 >
 >> 'how do we uniquely differ[distinguish] between them by name?'
 >>
 >> 'very costly (read: slow) sea[r]ch operations'
 >>
 >> (By the way, if you want to belong to multiple groups, is the only 
way to do
 >> this via an /etc/group file?
 >
 > You mean via the gr_mem field?  That's not evaluated anymore.  Group
 > membership is stored in SAM or AD.
No, I was just wondering: does AD allow you to be in multiple groups? It 
must, I suppose.  (It was an idle question, not really on the subject of 
the documentation.)
 >
 >
 >> Also, it occurs to me that another way to
 >> store the unix home dir, etc., would be a 'partial passwd' file that 
omitted
 >> the fields for the parts supplied easily by AD (SID, GID)?  That's 
just an
 >> idle thought.)
 >
 > But that means you have to read the files again.  Thre's not much of an
 > advantage to having full passwd and group files then for the user, nor
 > for Cygwin itself.  Plus, you have to implement two different reading
 > algos per file type.
True.  Forget it, dumb idea.
 >
 >> 'Cygwin process tree, which[ever?] first process'
 >
 > Hmm.  Sounds bad, right?
Um, awkward and not quite clear, yes.
 > What I'm trying to say is, if the first
 > process of a process tree found cygserver isn't started, it will not try
 > to ask cygserver again, and it will propagate the lack of cygserver to
 > the child processes, so they will neither try to contact cygserver.  If
 > you have a catchy way to phrase this in less words, I'd be quite happy.
 >
 > Btw.
 >
 > In the document I'm talking of the "first process of a Cygwin process
 > tree" throughout.  Is it clear at all what that means?

I think your description is reasonably clear.

 >  For a Cygwin
 > Terminal session that would be the mintty process.  If you have this:
 >
 >   Cygwin process 1 starts Cygwin process 2
 >   Cygwin process 2 starts CMD.EXE
 >   CMD.EXE starts Cygwin process 3
 >   Cygwin process 3 starts Cygwin process 4
 >
 > Then you have two Cygwin process trees with Cygwin process 1 and
 > Cygwin process 3 being the "first processes in a Cygwin process tree".
 >
 > Is there a better way to phrase this in English?  Would it make more
 > sense to use "parent" or "grandparent" for the first process?  Or
 > any other expression?

Hmm.

Well, you open the section by saying:

"The information fetched from file or the Windows account database is 
cached by the process. The cached information is inherited by child 
processes."

What about if you said:

"The information fetched (from file or from the Windows account 
database), is cached by the first process in the process tree. This 
cached information is inherited by every child process."

A little later you say:

"If cygserver is running it will provide passwd and group entry caching 
for all processes in a Cygwin process tree, which first process has been 
started after cygserver."

Maybe:

"If cygserver is running, it will provide passwd and group entry caching 
for all processes in every Cygwin process tree started after cygserver."

But what I hadn't realised until I read your reply, above, was that if 
you're not running cygserver, that if a Cygwin process is started from a 
Windows command in a Cygwin process tree, that new Cygwin process is the 
root of a new Cygwin process tree.

I wonder if the opening sentence should therefore say something like:

"The information fetched from file or the Windows account database is 
cached by the process. The cached information is inherited by child 
/Cygwin/ processes. (A Cygwin process invoked from a Windows command, 
such as CMD.exe, will start a fresh process tree unless /cygserver/ is 
running.)"

BTW, you could say "root of the process tree", but "root" tends to get 
confused with (superuser) root quite easily, so care would be needed.  I 
think "first process" is pretty clear.



 >> 'If both[,] files and db are specified'
 >
 > There is a comma already.  Or am I looking into the wrong line?

Sorry, I was too terse: the comma should be removed:
"If both files and db are specified..."

 >
 >> 'Cygwin will always try the files first, then the db. '
 >> -- is that because the db will always be more trustworthy than the 
files?
 >
 > It's because it doesn't make sense the other way around.  The DBs will
 > always have a valid reply for an existing account, thus there can't be
 > any fallback from db to files.

That's what I was trying to ask.  Thanks.  makes sense.

 >> BTW, the POSIX permission mapping leak used to have a section 
heading; it's
 >> now just unmarked, inside the File Permissions section.  (I'm just 
pointing
 >> that out.)
 >
 > That was deliberate.  I was wondering if the lengthy description of a
 > bordercase in permission handling really deserved its own chapter and
 > came up with a "no".

Perfectly reasonable.

 >> Hope this helps!  You've obviously put a lot of thought and effort 
into all
 >> this: thanks.
 >
 > This really helps a lot, thank you!  I applied a patch in your name,
 > hope that's ok.  I also uploaded this version to
 >
 >   https://cygwin.com/preliminary-ntsec.html
 >
 > If you (or somebody else) have suggestions for the two problems outlined
 > above, I'd be really grateful.
 >
 >
 > Thanks,
 > Corinna

I hope the above is of some help.

Regards,

luke



--
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] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 6664 bytes --]

On Oct 27 09:28, Luke Kendall wrote:
> On 24/10/14 21:37, Corinna Vinschen wrote:
> > On Oct 24 17:35, Luke Kendall wrote:
> >> On 24/10/14 02:43, Corinna Vinschen wrote:
> >>> On Oct 22 20:57, Tom Schutter wrote:
> >>>> On Wed 2014-10-22 11:23, Corinna Vinschen wrote:
> >>>>> For your convenience I wrote new documentation.  Since this is a TEST
> [snip]
> >>>>>
> >>>>>
> >>>>> 'Logon SIDs: The own[huh?  owner's?  user's?] LogonSid is converted'
> >
> > The logon SID of the current session.  I rephrased this now to:
> >
> > "Logon SIDs: The LogonSid of the current user's session is converted ..."
> >
> That's clear.
> >> 'if the AD administrators chose an unreasonable[unreasonably] small'
> >>
> >> 'which keeps an analogue value of the trustPosixOffset'
> >> -->
> >> 'which keeps an analog of the trustPosixOffset'
> >
> > British vs. American English...
> Sure, and I thought you'd prefer the American, but I'm happy to see British
> spelling.

So, so, it's always fun to wake up people with an unusual word ;)

> But the main point was to drop the word "value".  "A is an analog
> of B", not an analog /value/ of B.

Done.

> >> (By the way, if you want to belong to multiple groups, is the only way to
> do
> >> this via an /etc/group file?
> >
> > You mean via the gr_mem field?  That's not evaluated anymore.  Group
> > membership is stored in SAM or AD.
> No, I was just wondering: does AD allow you to be in multiple groups? It
> must, I suppose.  (It was an idle question, not really on the subject of the
> documentation.)

Questions are good!  Don't hesitate to ask them.  It shows that not
everything is clear enough.

And the anwser is, yes, just as on Linux or other UNIXy systems.  You
have one primary group ("None" on non-domain machines, default "Domain
Users" on domain machines), and an arbitrary number of supplementary
groups.  Have a look into the output of `id'.

> >> 'Cygwin process tree, which[ever?] first process'
> >
> > Hmm.  Sounds bad, right?
> Um, awkward and not quite clear, yes.
> > What I'm trying to say is, if the first
> > process of a process tree found cygserver isn't started, it will not try
> > to ask cygserver again, and it will propagate the lack of cygserver to
> > the child processes, so they will neither try to contact cygserver.  If
> > you have a catchy way to phrase this in less words, I'd be quite happy.
> >
> > Btw.
> >
> > In the document I'm talking of the "first process of a Cygwin process
> > tree" throughout.  Is it clear at all what that means?
> 
> I think your description is reasonably clear.
> 
> >  For a Cygwin
> > Terminal session that would be the mintty process.  If you have this:
> >
> >   Cygwin process 1 starts Cygwin process 2
> >   Cygwin process 2 starts CMD.EXE
> >   CMD.EXE starts Cygwin process 3
> >   Cygwin process 3 starts Cygwin process 4
> >
> > Then you have two Cygwin process trees with Cygwin process 1 and
> > Cygwin process 3 being the "first processes in a Cygwin process tree".
> >
> > Is there a better way to phrase this in English?  Would it make more
> > sense to use "parent" or "grandparent" for the first process?  Or
> > any other expression?
> 
> Hmm.
> 
> Well, you open the section by saying:
> 
> "The information fetched from file or the Windows account database is cached
> by the process. The cached information is inherited by child processes."
> 
> What about if you said:
> 
> "The information fetched (from file or from the Windows account database),
> is cached by the first process in the process tree. This cached information
> is inherited by every child process."

Uh, that wouldn't be quite right.  Every process calling getpwuid and
friends caches the account information it got.  So if process A starts
B, and B starts C, process C inherits the combined cached account 
information from A and B.

> A little later you say:
> 
> "If cygserver is running it will provide passwd and group entry caching for
> all processes in a Cygwin process tree, which first process has been started
> after cygserver."
> 
> Maybe:
> 
> "If cygserver is running, it will provide passwd and group entry caching for
> all processes in every Cygwin process tree started after cygserver."

Sounds much better.

> But what I hadn't realised until I read your reply, above, was that if
> you're not running cygserver, that if a Cygwin process is started from a
> Windows command in a Cygwin process tree, that new Cygwin process is the
> root of a new Cygwin process tree.
> 
> I wonder if the opening sentence should therefore say something like:
> 
> "The information fetched from file or the Windows account database is cached
> by the process. The cached information is inherited by child /Cygwin/
> processes. (A Cygwin process invoked from a Windows command, such as
> CMD.exe, will start a fresh process tree unless /cygserver/ is running.)"
> 
> BTW, you could say "root of the process tree", but "root" tends to get
> confused with (superuser) root quite easily, so care would be needed.  I
> think "first process" is pretty clear.

Ok, cool.  I rephrased the above a bit different:

  The information fetched from the Windows account database or the
  /etc/passwd and /etc/group files is cached by the process.  The cached
  information is inherited by Cygwin child processes.  A Cygwin process
  invoked from a Windows command, such as CMD.exe, will start a new
  Cygwin process tree and the caching starts from scratch (unless
  cygserver is running, but read on).

Is that ok?

> >> 'If both[,] files and db are specified'
> >
> > There is a comma already.  Or am I looking into the wrong line?
> 
> Sorry, I was too terse: the comma should be removed:
> "If both files and db are specified..."

Isn't that ambiguous?  What I was trying to say is:

  If both settings, "files" and "db" are specified...

Without the comma, the expression "both files" seems to refer to
the passwd and group files, not the setting I'm talking about,
and then I'm stumbling over the "... and db ...".

> I hope the above is of some help.

Very much so.  I'm very happy if you guys really care for the
documentation.  As a developer and as a non-native speaker, I'm never
quite sure if my expressions are intelligible enough for non-devs.

I updated https://cygwin.com/preliminary-ntsec.html according to
the above.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Luke Kendall]

On 27/10/14 23:39, Corinna Vinschen wrote:
 > On Oct 27 09:28, Luke Kendall wrote:
 >> On 24/10/14 21:37, Corinna Vinschen wrote:
 >>> On Oct 24 17:35, Luke Kendall wrote:
 >>>> On 24/10/14 02:43, Corinna Vinschen wrote:
[snip]
 >> Sure, and I thought you'd prefer the American, but I'm happy to see 
British
 >> spelling.
 >
 > So, so, it's always fun to wake up people with an unusual word


[...]
 >
 > And the anwser is, yes, just as on Linux or other UNIXy systems.  You
 > have one primary group ("None" on non-domain machines, default "Domain
 > Users" on domain machines), and an arbitrary number of supplementary
 > groups.  Have a look into the output of `id'.

Thanks!

 >>>> 'Cygwin process tree, which[ever?] first process'
 >>>
 >>> Hmm.  Sounds bad, right?
 >> Um, awkward and not quite clear, yes.
 >>> What I'm trying to say is, if the first
 >>> process of a process tree found cygserver isn't started, it will 
not try
 >>> to ask cygserver again, and it will propagate the lack of cygserver to
 >>> the child processes, so they will neither try to contact cygserver.  If
 >>> you have a catchy way to phrase this in less words, I'd be quite happy.
 >>>
 >>> Btw.
 >>>
 >>> In the document I'm talking of the "first process of a Cygwin process
 >>> tree" throughout.  Is it clear at all what that means?
 >>
 >> I think your description is reasonably clear.
 >>
 >>>   For a Cygwin
 >>> Terminal session that would be the mintty process.  If you have this:
 >>>
 >>>    Cygwin process 1 starts Cygwin process 2
 >>>    Cygwin process 2 starts CMD.EXE
 >>>    CMD.EXE starts Cygwin process 3
 >>>    Cygwin process 3 starts Cygwin process 4
 >>>
 >>> Then you have two Cygwin process trees with Cygwin process 1 and
 >>> Cygwin process 3 being the "first processes in a Cygwin process tree".
 >>>
 >>> Is there a better way to phrase this in English?  Would it make more
 >>> sense to use "parent" or "grandparent" for the first process?  Or
 >>> any other expression?
 >>
 >> Hmm.
 >>
 >> Well, you open the section by saying:
 >>
 >> "The information fetched from file or the Windows account database 
is cached
 >> by the process. The cached information is inherited by child processes."
 >>
 >> What about if you said:
 >>
 >> "The information fetched (from file or from the Windows account 
database),
 >> is cached by the first process in the process tree. This cached 
information
 >> is inherited by every child process."
 >
 > Uh, that wouldn't be quite right.  Every process calling getpwuid and
 > friends caches the account information it got.  So if process A starts
 > B, and B starts C, process C inherits the combined cached account
 > information from A and B.

Ah.

 >> A little later you say:
 >>
 >> "If cygserver is running it will provide passwd and group entry 
caching for
 >> all processes in a Cygwin process tree, which first process has been 
started
 >> after cygserver."
 >>
 >> Maybe:
 >>
 >> "If cygserver is running, it will provide passwd and group entry 
caching for
 >> all processes in every Cygwin process tree started after cygserver."
 >
 > Sounds much better.
 >
 >> But what I hadn't realised until I read your reply, above, was that if
 >> you're not running cygserver, that if a Cygwin process is started from a
 >> Windows command in a Cygwin process tree, that new Cygwin process is the
 >> root of a new Cygwin process tree.
 >>
 >> I wonder if the opening sentence should therefore say something like:
 >>
 >> "The information fetched from file or the Windows account database 
is cached
 >> by the process. The cached information is inherited by child /Cygwin/
 >> processes. (A Cygwin process invoked from a Windows command, such as
 >> CMD.exe, will start a fresh process tree unless /cygserver/ is 
running.)"
 >>
 >> BTW, you could say "root of the process tree", but "root" tends to get
 >> confused with (superuser) root quite easily, so care would be needed.  I
 >> think "first process" is pretty clear.
 >
 > Ok, cool.  I rephrased the above a bit different:
 >
 >    The information fetched from the Windows account database or the
 >    /etc/passwd and /etc/group files is cached by the process.  The cached
 >    information is inherited by Cygwin child processes.  A Cygwin process
 >    invoked from a Windows command, such as CMD.exe, will start a new
 >    Cygwin process tree and the caching starts from scratch (unless
 >    cygserver is running, but read on).
 >
 > Is that ok?

Yep, it's good and clear IMHO.

 >>>> 'If both[,] files and db are specified'
 >>>
 >>> There is a comma already.  Or am I looking into the wrong line?
 >>
 >> Sorry, I was too terse: the comma should be removed:
 >> "If both files and db are specified..."
 >
 > Isn't that ambiguous?  What I was trying to say is:
 >
 >    If both settings, "files" and "db" are specified...
 >
 > Without the comma, the expression "both files" seems to refer to
 > the passwd and group files, not the setting I'm talking about,
 > and then I'm stumbling over the "... and db ...".

I hadn't considered parsing it that way, and you're right.  But your 
phrasing 'If both settings, "files" and "db" are specified' is both 
unambiguous and also reads very naturally.

 >> I hope the above is of some help.
 >
 > Very much so.  I'm very happy if you guys really care for the
 > documentation.  As a developer and as a non-native speaker, I'm never
 > quite sure if my expressions are intelligible enough for non-devs.

It's good, and I (and I'm sure many others) appreciate the time and 
effort you put in.

 > I updated https://cygwin.com/preliminary-ntsec.html according to
 > the above.

Great!  And thanks again.

luke

 > Thanks,
 > Corinna
 >

--
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] TEST RELEASE: Cygwin 1.7.33-0.1

[Tom Schutter]

On Wed 2014-10-22 11:23, Corinna Vinschen wrote:
> The major change in this new release is the new method to read account
> (passwd and group) information from the Windows user databases directly,
> without the requirement to generate /etc/passwd and /etc/group files to
> generate Unix-like uid and gid.

What do you think the performance implications of this change will be?

-- 
Tom Schutter

--
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] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On October 23, 2014 5:00:03 AM CEST, Tom Schutter <t.schutter@comcast.net> wrote:
>On Wed 2014-10-22 11:23, Corinna Vinschen wrote:
>> The major change in this new release is the new method to read
>account
>> (passwd and group) information from the Windows user databases
>directly,
>> without the requirement to generate /etc/passwd and /etc/group files
>to
>> generate Unix-like uid and gid.
>
>What do you think the performance implications of this change will be?

For most home users there will be not much of a difference, probably, but I'm not sure.

The older method reading the files was slow, because each exec'ed process had to reread the entire passwd and group files anew.  With small files this was probably sufficiently fast.

The new method will not have to read any files, though.  It reads all infos from the local SAM, and it cashes the user and primary group data right fron the start.  If i may hazard a guess, it should be slightly faster for most people.

For AD users the answer is probably an "it depends".  A slow network might be a problem.  But one advantage always is: No more reading /etc/passwd and /etc/group files in each exec'ed process.

Corinna
- --
Corinna Vinschen                   Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQJEBAEBCgAuBQJUSJzOJxxDb3Jpbm5hIFZpbnNjaGVuIDxjb3Jpbm5hQHZpbnNj
aGVuLmRlPgAKCRD1NgadrkRPoFrJD/sGpUaz/l4ENPsXQmVGph1ZPrkeT60etgQU
MOh25sg9/V9td3cDnxX7gLZeGQL+vCeYJFIKuzAtmoO5Ez/7ztfmvK1qHxK4DE3J
0MYL3SDSEm3xFUcxu5Qx58MwXBuupzPz3cC1xI493cmsBHkTHNGf5SLLrKUVIfTY
luB6eURygPXm5CDRz2sgstm1AiUfQEqyzl/Pp7b8iESaPEd+rVXjoVmAxcJVEQoT
AItBmG3eGy8sLUq1DlkYl8V8nThdCD9LyBxeZlNH7N2T3zyceVnCXF6mIb9127Bs
uISei5z+ATDsYFm04dfhgAmJcrQxT2S/XxYwEeO9XxpngpyCcB32EWB0OcRuFOxu
xcd6FS4uLYZetIOegXAixsH5JHqDSboW+LPGETpL73tX6vr/gg/q2pOKRhwU4FSo
mBF/pqG4B1vXjJqDkM46QKBjoClQSOcWIJiIVzwz/PTHXVFO2dm7MyeuvBDTz2h7
RBaBrjYdz3OF80SgXQFakbXXg5/dOzyJfHRPQcpvSfPG7wuOY3wSXsiH5vyB/k6x
A+LhNqHi0C8DkB9Pja9DKuLlte7g+YapSfDsfKJrKucq2QovVsrDszqhnxwMkAsQ
sUPH0+7UOonDQ1lyyGSfNkFV7H44gZF0XfiEcxNXdOJu1pIXut6nmVK7QYDouOtB
Jt3XsHPUug==
=f5z+
-----END PGP SIGNATURE-----


--
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] TEST RELEASE: Cygwin 1.7.33-0.1

[Achim Gratz]

Tom Schutter writes:
> On Wed 2014-10-22 11:23, Corinna Vinschen wrote:
>> The major change in this new release is the new method to read account
>> (passwd and group) information from the Windows user databases directly,
>> without the requirement to generate /etc/passwd and /etc/group files to
>> generate Unix-like uid and gid.
>
> What do you think the performance implications of this change will be?

In my experience Cygwin starts up quite a bit faster actually.  If a
program tries to enumerate the complete domain then yes that would be
slow if your domain is large, but then you can use /etc/nsswitch.conf to
forbid that.


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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Andrey Repin]

Greetings, Tom Schutter!

>> The major change in this new release is the new method to read account
>> (passwd and group) information from the Windows user databases directly,
>> without the requirement to generate /etc/passwd and /etc/group files to
>> generate Unix-like uid and gid.

> What do you think the performance implications of this change will be?

For me, it was a great improvement, except some rare (and largely unusual) cases.
And I didn't repeat the tests with latest incarnation of this feature.
You can check the mail archives for details.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 24.10.2014, <1:51>

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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Denis Excoffier]

On 2014-10-22 11:23, Corinna Vinschen wrote:
> 
> - Drop the current working directory from the default DLL search path in
>  favor of Cygwin's /bin dir.
I'm not so comfortable with this one.

I use
PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog

There is no DLL at all in /my/otherdir (this is the very first place
for Windows to look for DLL's, and i think that this cannot change).
In /my/dir/bin, there is an updated version of a library also
located in /usr/bin, for example an updated cygstdc++-6.dll (from GCC 4.9.1).

Does this mean that, under this change, cygstdc++-6.dll will be found
in /usr/bin and not in /my/dir/bin ? In fact, this is what i can
observe personnally.

Also, i don't remember that the CWD has an impact on where DLL is found (apart
from being in PATH, and apart from being the dir where the exe resides).

For a test i have commented out in cygheap.cc the line
'wcpncpy (installation_dir, ...' (and also the next one)
and the old behaviour is now back.

It seems to me that this change is a regression. Could someone please argue?

Regards,

Denis Excoffier.





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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]

On Oct 23 20:06, Denis Excoffier wrote:
> On 2014-10-22 11:23, Corinna Vinschen wrote:
> > 
> > - Drop the current working directory from the default DLL search path in
> >  favor of Cygwin's /bin dir.
> I'm not so comfortable with this one.
> 
> I use
> PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog
> 
> There is no DLL at all in /my/otherdir (this is the very first place
> for Windows to look for DLL's, and i think that this cannot change).
> In /my/dir/bin, there is an updated version of a library also
> located in /usr/bin, for example an updated cygstdc++-6.dll (from GCC 4.9.1).
> 
> Does this mean that, under this change, cygstdc++-6.dll will be found
> in /usr/bin and not in /my/dir/bin ? In fact, this is what i can
> observe personnally.
> 
> Also, i don't remember that the CWD has an impact on where DLL is found (apart
> from being in PATH, and apart from being the dir where the exe resides).
> 
> For a test i have commented out in cygheap.cc the line
> 'wcpncpy (installation_dir, ...' (and also the next one)
> and the old behaviour is now back.
> 
> It seems to me that this change is a regression. Could someone please argue?

Hmm.  It's hard to do the right thing here, I guess.  I can see how
this is a regression in your scenario.  OTOH, your scenario is not
stable.  The directories in $PATH are the last ones in the DLL search
order.  So, your scenario already wouldn't work if your CWD is /bin
(or /usr/bin).

From Cygwin's POV {/usr}/bin is a system dir.  For security reasons it
makes sense that the system DLLs in /bin cannot be overridden, unless
it's an installation issue which should be covered by looking into the
application installation dir first.

Having said that, moving your DLLs into the application dir is really
not an option?

Does anybody else have a similar scenario to cover, which doesn't work
anymore with this change?


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Denis Excoffier]

> On 2014-10-24 13:02, Corinna Vinschen wrote:
> 
> On Oct 23 20:06, Denis Excoffier wrote:
>> On 2014-10-22 11:23, Corinna Vinschen wrote:
>>> 
>>> - Drop the current working directory from the default DLL search path in
>>> favor of Cygwin's /bin dir.
>> I'm not so comfortable with this one.
>> 
>> I use
>> PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog
>> 
>> There is no DLL at all in /my/otherdir (this is the very first place
>> for Windows to look for DLL's, and i think that this cannot change).
>> In /my/dir/bin, there is an updated version of a library also
>> located in /usr/bin, for example an updated cygstdc++-6.dll (from GCC 4.9.1).
>> 
>> Does this mean that, under this change, cygstdc++-6.dll will be found
>> in /usr/bin and not in /my/dir/bin ? In fact, this is what i can
>> observe personnally.
>> 
>> Also, i don't remember that the CWD has an impact on where DLL is found (apart
>> from being in PATH, and apart from being the dir where the exe resides).
>> 
>> For a test i have commented out in cygheap.cc the line
>> 'wcpncpy (installation_dir, ...' (and also the next one)
>> and the old behaviour is now back.
>> 
>> It seems to me that this change is a regression. Could someone please argue?
> 
> Hmm.  It's hard to do the right thing here, I guess.  I can see how
> this is a regression in your scenario.  OTOH, your scenario is not
> stable.  The directories in $PATH are the last ones in the DLL search
> order.  So, your scenario already wouldn't work if your CWD is /bin
> (or /usr/bin).
Typically, the line 'PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog' is
in a Makefile, as part of some 'make check'. I don't usually build
from /usr/bin.
I was not aware that CWD was useful. IIUC, your change removes the lookup
into CWD (and replaces with a lookup to somewhere else). Who needs CWD at
the first place? These people (or specification?) will not be OK now.

> 
> From Cygwin's POV {/usr}/bin is a system dir.  For security reasons it
> makes sense that the system DLLs in /bin cannot be overridden, unless
> it's an installation issue which should be covered by looking into the
> application installation dir first.

Instead of adding the lookup of /usr/bin before the PATH, you could add
it afterwards? Or do you mean that my use is bad practice for security
reasons? That there might be some unexpected DLL somewhere in the PATH?
IIRC, in linux/solaris, LD_LIBRARY_PATH is not honored when you are root,
not otherwise.
> 
> Having said that, moving your DLLs into the application dir is really
> not an option?
Oh yes, i use it all the time. It is the job of 'make install' to also
install the appropriate DLLs. The point here is for 'make check'.
> 
> Does anybody else have a similar scenario to cover, which doesn't work
> anymore with this change?
Yes please?

Regards,

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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 4486 bytes --]

[Christian, please chime in]

On Oct 24 20:41, Denis Excoffier wrote:
> > On 2014-10-24 13:02, Corinna Vinschen wrote:
> > On Oct 23 20:06, Denis Excoffier wrote:
> >> On 2014-10-22 11:23, Corinna Vinschen wrote:
> >>> 
> >>> - Drop the current working directory from the default DLL search path in
> >>> favor of Cygwin's /bin dir.
> >> I'm not so comfortable with this one.
> >> 
> >> I use
> >> PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog
> >> 
> >> There is no DLL at all in /my/otherdir (this is the very first place
> >> for Windows to look for DLL's, and i think that this cannot change).
> >> In /my/dir/bin, there is an updated version of a library also
> >> located in /usr/bin, for example an updated cygstdc++-6.dll (from GCC 4.9.1).
> >> 
> >> Does this mean that, under this change, cygstdc++-6.dll will be found
> >> in /usr/bin and not in /my/dir/bin ? In fact, this is what i can
> >> observe personnally.
> >> 
> >> Also, i don't remember that the CWD has an impact on where DLL is found (apart
> >> from being in PATH, and apart from being the dir where the exe resides).
> >> 
> >> For a test i have commented out in cygheap.cc the line
> >> 'wcpncpy (installation_dir, ...' (and also the next one)
> >> and the old behaviour is now back.
> >> 
> >> It seems to me that this change is a regression. Could someone please argue?
> > 
> > Hmm.  It's hard to do the right thing here, I guess.  I can see how
> > this is a regression in your scenario.  OTOH, your scenario is not
> > stable.  The directories in $PATH are the last ones in the DLL search
> > order.  So, your scenario already wouldn't work if your CWD is /bin
> > (or /usr/bin).
> Typically, the line 'PATH=/my/dir/bin:/usr/bin /my/otherdir/myprog' is
> in a Makefile, as part of some 'make check'. I don't usually build
> from /usr/bin.

Sure.  I was just pointing out that it's not a 100% stable method, but
dependent on the system's DLL search order, your CWD, and the fact that
the application is not installed into {/usr}/bin.

> I was not aware that CWD was useful. IIUC, your change removes the lookup
> into CWD (and replaces with a lookup to somewhere else). Who needs CWD at
> the first place? These people (or specification?) will not be OK now.

If applications do this:

  chdir("/path/of/DLLs");
  dlopen("some.dll");

it wouldn't work anymore.  It wouldn't work on Linux either, unless CWD
is in LD_LIBRARY_PATH or the default search path.  This would work,
though:

  chdir("/path/of/DLLs");
  dlopen("/path/of/DLLs/some.dll");

Unfortunately the same doesn't work if the application calls execve
instead of dlopen because we can't add our LD_LIBRARY_PATH magic
there.

> > From Cygwin's POV {/usr}/bin is a system dir.  For security reasons it
> > makes sense that the system DLLs in /bin cannot be overridden, unless
> > it's an installation issue which should be covered by looking into the
> > application installation dir first.
> 
> Instead of adding the lookup of /usr/bin before the PATH, you could add
> it afterwards?

No.  You don't expect this kind of flexibility in the Win32 API, do you?
The way it works is, there's a call SetDllDirectory which replaces the "."
in the DLL search path with the directory given as argument.  The search
order is always this:

  application dir
  dir given in SetDllDirecory (Cygwin's bin)
  system dirs
  $PATH

> Or do you mean that my use is bad practice for security
> reasons? That there might be some unexpected DLL somewhere in the PATH?
> IIRC, in linux/solaris, LD_LIBRARY_PATH is not honored when you are root,
> not otherwise.

Not quite.  LD_LIBRARY_PATH is only ignored if the excutable is a
suid/sgid executable.  Unfortunately we don't have LD_LIBRARY_PATH at
all when running execve (but we have in dlopen).

> > Having said that, moving your DLLs into the application dir is really
> > not an option?
> Oh yes, i use it all the time. It is the job of 'make install' to also
> install the appropriate DLLs. The point here is for 'make check'.

Yeah.

Sigh.

I don't like the idea either that this simple change breaks existing
scenarios.  I'm inclined to revert this change.

Christian, would you mind terribly to re-add the tweak to postfix
to set $PATH?


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Christian Franke]

Corinna Vinschen wrote:
> [Christian, please chime in]
>
> On Oct 24 20:41, Denis Excoffier wrote:
>>>  From Cygwin's POV {/usr}/bin is a system dir.  For security reasons it
>>> makes sense that the system DLLs in /bin cannot be overridden, unless
>>> it's an installation issue which should be covered by looking into the
>>> application installation dir first.
>> Instead of adding the lookup of /usr/bin before the PATH, you could add
>> it afterwards?
> No.  You don't expect this kind of flexibility in the Win32 API, do you?

[The *LIBPATH variables from MS OS/2 (1987) never made it to Win API :-]


> The way it works is, there's a call SetDllDirectory which replaces the "."
> in the DLL search path with the directory given as argument.  The search
> order is always this:
>
>    application dir
>    dir given in SetDllDirecory (Cygwin's bin)
>    system dirs
>    $PATH
>
>> Or do you mean that my use is bad practice for security
>> reasons? That there might be some unexpected DLL somewhere in the PATH?
>> IIRC, in linux/solaris, LD_LIBRARY_PATH is not honored when you are root,
>> not otherwise.
> Not quite.  LD_LIBRARY_PATH is only ignored if the excutable is a
> suid/sgid executable.  Unfortunately we don't have LD_LIBRARY_PATH at
> all when running execve (but we have in dlopen).
>
>>> Having said that, moving your DLLs into the application dir is really
>>> not an option?
>> Oh yes, i use it all the time. It is the job of 'make install' to also
>> install the appropriate DLLs. The point here is for 'make check'.
> Yeah.
>
> Sigh.
>
> I don't like the idea either that this simple change breaks existing
> scenarios.  I'm inclined to revert this change.
>
> Christian, would you mind terribly to re-add the tweak to postfix
> to set $PATH?
>

No problem.

Another possible solution:
Check for e.g. CYGWIN_DLLPATH environment variable before calling 
SetDllDirectory().

If unset or empty, call SetDllDirectory("X:\path_to_cygwin\bin");
else if set to ".", do nothing.
else call SetDllDirectory(CYGWIN_DLLPATH);

The above 'make check' should then work again as 'CYGWIN_DLLPATH=. make 
check'.

Possible enhancement: If AddDllDirectory() is available (>= Win8), 
accept a real search path in CYGWIN_DLLPATH.

Christian


--
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] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3296 bytes --]

On Oct 24 22:16, Christian Franke wrote:
> Corinna Vinschen wrote:
> >[Christian, please chime in]
> >
> >On Oct 24 20:41, Denis Excoffier wrote:
> >>> From Cygwin's POV {/usr}/bin is a system dir.  For security reasons it
> >>>makes sense that the system DLLs in /bin cannot be overridden, unless
> >>>it's an installation issue which should be covered by looking into the
> >>>application installation dir first.
> >>Instead of adding the lookup of /usr/bin before the PATH, you could add
> >>it afterwards?
> >No.  You don't expect this kind of flexibility in the Win32 API, do you?
> 
> [The *LIBPATH variables from MS OS/2 (1987) never made it to Win API :-]
> 
> 
> >The way it works is, there's a call SetDllDirectory which replaces the "."
> >in the DLL search path with the directory given as argument.  The search
> >order is always this:
> >
> >   application dir
> >   dir given in SetDllDirecory (Cygwin's bin)
> >   system dirs
> >   $PATH
> >
> >>Or do you mean that my use is bad practice for security
> >>reasons? That there might be some unexpected DLL somewhere in the PATH?
> >>IIRC, in linux/solaris, LD_LIBRARY_PATH is not honored when you are root,
> >>not otherwise.
> >Not quite.  LD_LIBRARY_PATH is only ignored if the excutable is a
> >suid/sgid executable.  Unfortunately we don't have LD_LIBRARY_PATH at
> >all when running execve (but we have in dlopen).
> >
> >>>Having said that, moving your DLLs into the application dir is really
> >>>not an option?
> >>Oh yes, i use it all the time. It is the job of 'make install' to also
> >>install the appropriate DLLs. The point here is for 'make check'.
> >Yeah.
> >
> >Sigh.
> >
> >I don't like the idea either that this simple change breaks existing
> >scenarios.  I'm inclined to revert this change.
> >
> >Christian, would you mind terribly to re-add the tweak to postfix
> >to set $PATH?
> >
> 
> No problem.

Thanks, I'm relieved.

> Another possible solution:
> Check for e.g. CYGWIN_DLLPATH environment variable before calling
> SetDllDirectory().
> 
> If unset or empty, call SetDllDirectory("X:\path_to_cygwin\bin");
> else if set to ".", do nothing.
> else call SetDllDirectory(CYGWIN_DLLPATH);
> 
> The above 'make check' should then work again as 'CYGWIN_DLLPATH=. make
> check'.

Hmm.  This requirement to set CYGWIN_DLLPATH would be far from obvious
for the user, though.

> Possible enhancement: If AddDllDirectory() is available (>= Win8), accept a
> real search path in CYGWIN_DLLPATH.

Per MSDN, AddDllDirectory only works for LoadLibrary{Ex}, and the DLL
search order when using SetDefaultDllDirectories looks entirely
different from the other default search orders(*).

Even if it works for CreateProcess as well, the probably worst problem
is that $PATH is not evaluated anymore.

OTOH, this might allow us to redefine the DLL search path in a way which
enables LD_LIBRARY_PATH handling for Cygwin, but a patch to use this
stuff would be pretty intrusive.


Thanks,
Corinna


(*) http://msdn.microsoft.com/en-us/library/windows/desktop/hh310515%28v=vs.85%29.aspx

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Denis Excoffier]

2014-10-24 22:16, Christian Franke wrote:
> 
> Corinna Vinschen wrote:
>> 
>> Sigh.
>> 
>> I don't like the idea either that this simple change breaks existing
>> scenarios.  I'm inclined to revert this change.
>> 
>> Christian, would you mind terribly to re-add the tweak to postfix
>> to set $PATH?
>> 
> 
> No problem.
> 
> Another possible solution:
> Check for e.g. CYGWIN_DLLPATH environment variable before calling SetDllDirectory().
> 
> If unset or empty, call SetDllDirectory("X:\path_to_cygwin\bin");
> else if set to ".", do nothing.
> else call SetDllDirectory(CYGWIN_DLLPATH);
> 
> The above 'make check' should then work again as 'CYGWIN_DLLPATH=. make check'.
I can buy this. Setting 'export CYGWIN_DLLPATH := .' at the beginning of the Makefile will
do the job.

> 
> Possible enhancement: If AddDllDirectory() is available (>= Win8), accept a real search path in CYGWIN_DLLPATH.
Also perhaps you can use yet another subitem in the CYGWIN environment variable?

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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

On Oct 24 23:17, Denis Excoffier wrote:
> 2014-10-24 22:16, Christian Franke wrote:
> > 
> > Corinna Vinschen wrote:
> >> 
> >> Sigh.
> >> 
> >> I don't like the idea either that this simple change breaks existing
> >> scenarios.  I'm inclined to revert this change.
> >> 
> >> Christian, would you mind terribly to re-add the tweak to postfix
> >> to set $PATH?
> >> 
> > 
> > No problem.
> > 
> > Another possible solution:
> > Check for e.g. CYGWIN_DLLPATH environment variable before calling SetDllDirectory().
> > 
> > If unset or empty, call SetDllDirectory("X:\path_to_cygwin\bin");
> > else if set to ".", do nothing.
> > else call SetDllDirectory(CYGWIN_DLLPATH);
> > 
> > The above 'make check' should then work again as 'CYGWIN_DLLPATH=. make check'.
> I can buy this. Setting 'export CYGWIN_DLLPATH := .' at the beginning of the Makefile will
> do the job.
> 
> > 
> > Possible enhancement: If AddDllDirectory() is available (>= Win8), accept a real search path in CYGWIN_DLLPATH.
> Also perhaps you can use yet another subitem in the CYGWIN environment variable?

If AddDllDirectory works without much hassle, which I have to test first,
why introduce CYGWIN_DLLPATH or another CYGWIN item?

LD_LIBRARY_PATH would be the one we want then, wouldn't it?


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2221 bytes --]

On Oct 25 13:10, Corinna Vinschen wrote:
> On Oct 24 23:17, Denis Excoffier wrote:
> > 2014-10-24 22:16, Christian Franke wrote:
> > > Another possible solution:
> > > Check for e.g. CYGWIN_DLLPATH environment variable before calling SetDllDirectory().
> > > 
> > > If unset or empty, call SetDllDirectory("X:\path_to_cygwin\bin");
> > > else if set to ".", do nothing.
> > > else call SetDllDirectory(CYGWIN_DLLPATH);
> > > 
> > > The above 'make check' should then work again as 'CYGWIN_DLLPATH=. make check'.
> > I can buy this. Setting 'export CYGWIN_DLLPATH := .' at the beginning of the Makefile will
> > do the job.
> > 
> > > 
> > > Possible enhancement: If AddDllDirectory() is available (>= Win8), accept a real search path in CYGWIN_DLLPATH.
> > Also perhaps you can use yet another subitem in the CYGWIN environment variable?
> 
> If AddDllDirectory works without much hassle, which I have to test first,
> why introduce CYGWIN_DLLPATH or another CYGWIN item?
> 
> LD_LIBRARY_PATH would be the one we want then, wouldn't it?

One really big problem with AddDllDirectory is this:  While you can add
multiple directories to the search path, the order in which these
directories are added does not specify a search order.  In fact, the
order in which the paths are searched is unspecified per MSDN.

In Denis example that means, if we add /usr/bin and /my/dir/bin to the
DLL search path, Denis case works or it doesn't, and we never know when
it will work and when it won't, and we have no way to influence this.
Oh boy.

Apart from SetDllDirectory and AddDllDirectory, what about this very
simple solution in Cygwin:

- Don't call SetDllDirectory at all, thus "." is kept in the search
  path.

- In execve, when creating the Windows environment for the child process,
  check if $PATH is empty.  If so, set $PATH to /bin for the child.
  Or, check if /bin is in $PATH, if not, add it.

That would catch both problems, backward compatibility with Denis
scenario, as well as the PATH setting in postfix.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Denis Excoffier]

On 2014-10-25 16:49, Corinna Vinschen wrote:
> 
> On Oct 25 13:10, Corinna Vinschen wrote:
>> On Oct 24 23:17, Denis Excoffier wrote:
>>> 2014-10-24 22:16, Christian Franke wrote:
>>>> Another possible solution:
>>>> Check for e.g. CYGWIN_DLLPATH environment variable before calling SetDllDirectory().
>>>> 
>>>> If unset or empty, call SetDllDirectory("X:\path_to_cygwin\bin");
>>>> else if set to ".", do nothing.
>>>> else call SetDllDirectory(CYGWIN_DLLPATH);
>>>> 
>>>> The above 'make check' should then work again as 'CYGWIN_DLLPATH=. make check'.
>>> I can buy this. Setting 'export CYGWIN_DLLPATH := .' at the beginning of the Makefile will
>>> do the job.
>>> 
>>>> 
>>>> Possible enhancement: If AddDllDirectory() is available (>= Win8), accept a real search path in CYGWIN_DLLPATH.
>>> Also perhaps you can use yet another subitem in the CYGWIN environment variable?
>> 
>> If AddDllDirectory works without much hassle, which I have to test first,
Doesn't the "(>= Win8)" (a few lines before) prevent this scenario from working with XP SP3?
>> why introduce CYGWIN_DLLPATH or another CYGWIN item?
>> 
>> LD_LIBRARY_PATH would be the one we want then, wouldn't it?
> 
> One really big problem with AddDllDirectory is this:  While you can add
> multiple directories to the search path, the order in which these
> directories are added does not specify a search order.  In fact, the
> order in which the paths are searched is unspecified per MSDN.
> 
> In Denis example that means, if we add /usr/bin and /my/dir/bin to the
> DLL search path, Denis case works or it doesn't, and we never know when
> it will work and when it won't, and we have no way to influence this.
> Oh boy.
> 
> Apart from SetDllDirectory and AddDllDirectory, what about this very
> simple solution in Cygwin:
> 
> - Don't call SetDllDirectory at all, thus "." is kept in the search
>  path.
> 
> - In execve, when creating the Windows environment for the child process,
>  check if $PATH is empty.  If so, set $PATH to /bin for the child.
>  Or, check if /bin is in $PATH, if not, add it.
Then you may add it at the beginning. People that would want it at the end (or
elsewhere) can insert it explicitly. Also make sure to consider /usr/bin and /bin
as being equivalent here.

However, modifying PATH behind the scenes may be considered as an unexpected
intrusion by the user (PATH is for user consumption isn't it?). Aren't there
any legitimate scenarios where the user would omit /usr/bin from the PATH?

Is it possible to SetDllDirectory("/usr/bin") only if /usr/bin is _not_ in PATH?
This would be less intrusive.
> 
> That would catch both problems, backward compatibility with Denis
> scenario, as well as the PATH setting in postfix.
This corresponds to my current patched cygwin1.dll (where i commented out 2 lines
in cygheap.cc, see previous messages), since i keep /usr/bin in PATH.

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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

On Oct 25 19:29, Denis Excoffier wrote:
> On 2014-10-25 16:49, Corinna Vinschen wrote:
> > Apart from SetDllDirectory and AddDllDirectory, what about this very
> > simple solution in Cygwin:
> > 
> > - Don't call SetDllDirectory at all, thus "." is kept in the search
> >  path.
> > 
> > - In execve, when creating the Windows environment for the child process,
> >  check if $PATH is empty.  If so, set $PATH to /bin for the child.
> >  Or, check if /bin is in $PATH, if not, add it.
>
> Then you may add it at the beginning. People that would want it at the
> end (or elsewhere) can insert it explicitly.

Appending it to PATH doesn't change the search order, prepending does.
Also, appending is the faster technique, especially in this context in
the code.

> Also make sure to consider /usr/bin and /bin as being equivalent here.

This functionality would test the Windows path, not the POSIX path.

> However, modifying PATH behind the scenes may be considered as an
> unexpected intrusion by the user (PATH is for user consumption isn't
> it?). Aren't there any legitimate scenarios where the user would omit
> /usr/bin from the PATH?

No, not really.

> Is it possible to SetDllDirectory("/usr/bin") only if /usr/bin is
> _not_ in PATH?  This would be less intrusive.

This would potentially break your scenario again.  The /bin dir would be
search before your PATH settings again.  Yes, you always have /bin in
PATH, but I'm thinking of the general case.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Christian Franke]

Corinna Vinschen wrote:
> On Oct 25 13:10, Corinna Vinschen wrote:
>> On Oct 24 23:17, Denis Excoffier wrote:
>>> 2014-10-24 22:16, Christian Franke wrote:
>>>> Another possible solution:
>>>> Check for e.g. CYGWIN_DLLPATH environment variable before calling SetDllDirectory().
>>>>
>>>> If unset or empty, call SetDllDirectory("X:\path_to_cygwin\bin");
>>>> else if set to ".", do nothing.
>>>> else call SetDllDirectory(CYGWIN_DLLPATH);
>>>>
>>>> The above 'make check' should then work again as 'CYGWIN_DLLPATH=. make check'.
>>> I can buy this. Setting 'export CYGWIN_DLLPATH := .' at the beginning of the Makefile will
>>> do the job.
>>>
>>>> Possible enhancement: If AddDllDirectory() is available (>= Win8), accept a real search path in CYGWIN_DLLPATH.
>>> Also perhaps you can use yet another subitem in the CYGWIN environment variable?
>> If AddDllDirectory works without much hassle, which I have to test first,
>> why introduce CYGWIN_DLLPATH or another CYGWIN item?
>>
>> LD_LIBRARY_PATH would be the one we want then, wouldn't it?
> One really big problem with AddDllDirectory is this:  While you can add
> multiple directories to the search path, the order in which these
> directories are added does not specify a search order.  In fact, the
> order in which the paths are searched is unspecified per MSDN.
>
> In Denis example that means, if we add /usr/bin and /my/dir/bin to the
> DLL search path, Denis case works or it doesn't, and we never know when
> it will work and when it won't, and we have no way to influence this.
> Oh boy.
>
> Apart from SetDllDirectory and AddDllDirectory, what about this very
> simple solution in Cygwin:
>
> - Don't call SetDllDirectory at all, thus "." is kept in the search
>    path.
>
> - In execve, when creating the Windows environment for the child process,
>    check if $PATH is empty.  If so, set $PATH to /bin for the child.
>    Or, check if /bin is in $PATH, if not, add it.
>
> That would catch both problems, backward compatibility with Denis
> scenario, as well as the PATH setting in postfix.

OK for me. For postfix, the '$PATH is empty' check would be sufficient.

Christian


--
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] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2770 bytes --]

On Oct 27 07:31, Christian Franke wrote:
> Corinna Vinschen wrote:
> >On Oct 25 13:10, Corinna Vinschen wrote:
> >>On Oct 24 23:17, Denis Excoffier wrote:
> >>>2014-10-24 22:16, Christian Franke wrote:
> >>>>Another possible solution:
> >>>>Check for e.g. CYGWIN_DLLPATH environment variable before calling SetDllDirectory().
> >>>>
> >>>>If unset or empty, call SetDllDirectory("X:\path_to_cygwin\bin");
> >>>>else if set to ".", do nothing.
> >>>>else call SetDllDirectory(CYGWIN_DLLPATH);
> >>>>
> >>>>The above 'make check' should then work again as 'CYGWIN_DLLPATH=. make check'.
> >>>I can buy this. Setting 'export CYGWIN_DLLPATH := .' at the beginning of the Makefile will
> >>>do the job.
> >>>
> >>>>Possible enhancement: If AddDllDirectory() is available (>= Win8), accept a real search path in CYGWIN_DLLPATH.
> >>>Also perhaps you can use yet another subitem in the CYGWIN environment variable?
> >>If AddDllDirectory works without much hassle, which I have to test first,
> >>why introduce CYGWIN_DLLPATH or another CYGWIN item?
> >>
> >>LD_LIBRARY_PATH would be the one we want then, wouldn't it?
> >One really big problem with AddDllDirectory is this:  While you can add
> >multiple directories to the search path, the order in which these
> >directories are added does not specify a search order.  In fact, the
> >order in which the paths are searched is unspecified per MSDN.
> >
> >In Denis example that means, if we add /usr/bin and /my/dir/bin to the
> >DLL search path, Denis case works or it doesn't, and we never know when
> >it will work and when it won't, and we have no way to influence this.
> >Oh boy.
> >
> >Apart from SetDllDirectory and AddDllDirectory, what about this very
> >simple solution in Cygwin:
> >
> >- Don't call SetDllDirectory at all, thus "." is kept in the search
> >   path.
> >
> >- In execve, when creating the Windows environment for the child process,
> >   check if $PATH is empty.  If so, set $PATH to /bin for the child.
> >   Or, check if /bin is in $PATH, if not, add it.
> >
> >That would catch both problems, backward compatibility with Denis
> >scenario, as well as the PATH setting in postfix.
> 
> OK for me. For postfix, the '$PATH is empty' check would be sufficient.

Thanks, I applied a patch to add the Windows version of /bin to the
Windows environment when spawning a new process.  Checking if $PATH
contains this dir is a bit awkward.  If it really turns out to be
necessary at one point, we can add it then.

I'm going to create a 1.7.33-0.3 test release later today.


Thanks guys,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Andrey Repin]

Greetings, Corinna Vinschen!

>> >- In execve, when creating the Windows environment for the child process,
>> >   check if $PATH is empty.  If so, set $PATH to /bin for the child.
>> >   Or, check if /bin is in $PATH, if not, add it.
>> >
>> >That would catch both problems, backward compatibility with Denis
>> >scenario, as well as the PATH setting in postfix.
>> 
>> OK for me. For postfix, the '$PATH is empty' check would be sufficient.

> Thanks, I applied a patch to add the Windows version of /bin to the
> Windows environment when spawning a new process.  Checking if $PATH
> contains this dir is a bit awkward.  If it really turns out to be
> necessary at one point, we can add it then.

Wouldn't that increase the chance of triggering the bug of environment block
growing too big?

> I'm going to create a 1.7.33-0.3 test release later today.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 27.10.2014, <16:33>

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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

On Oct 27 16:34, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> >> >- In execve, when creating the Windows environment for the child process,
> >> >   check if $PATH is empty.  If so, set $PATH to /bin for the child.
> >> >   Or, check if /bin is in $PATH, if not, add it.
> >> >
> >> >That would catch both problems, backward compatibility with Denis
> >> >scenario, as well as the PATH setting in postfix.
> >> 
> >> OK for me. For postfix, the '$PATH is empty' check would be sufficient.
> 
> > Thanks, I applied a patch to add the Windows version of /bin to the
> > Windows environment when spawning a new process.  Checking if $PATH
> > contains this dir is a bit awkward.  If it really turns out to be
> > necessary at one point, we can add it then.
> 
> Wouldn't that increase the chance of triggering the bug of environment block
> growing too big?

- If PATH is empty, starting any Cygwin process will fail.

- Adding a few bytes, ~40 in my case, shouldn't really matter.

- Cygwin is creating a UNICODE environment.  The call to CreateProcess
  has no size restriction when using a UNICODE environment.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Andrey Repin]

Greetings, Corinna Vinschen!

> For your convenience I wrote new documentation.  Since this is a TEST
> prerelease, the new documentation is not part of the official docs yet.
> Rather have a look at

>   https://cygwin.com/preliminary-ntsec.html

"via an undocumented APIr " should be "... API, " probably.

> If you read it
> (which I seriously hope for) and it's all just incomprehensible
> gobbledygook to you, please say so on the mailing list

>   cygwin AT cygwin DOT com

> so we have a chance to improve the documentation.

I'm in the process of reading it. Goes slowly, but that's due to my head
condition. It really a very good read, thank you.

> - /proc/cygdrive is a new symlink pointing to the current cygdrive prefix.
>   This can be utilized in scripts to access paths via cygdrive prefix, even
>   if the cygdrive prefix has been changed by the user.

Hm. The prefix currently set to just "/".

$ ls -l /proc/cygdrive
lrwxrwxrwx 1 anrdaemon None 0 Oct 24 20:17 /proc/cygdrive -> /proc/cygdrive

$ ls -l /proc/cygdrive/
ls: cannot access /proc/cygdrive/: Not a directory

Is this... normal?
Or what this is supposed to be at all? Shouldn't it be a simple text file
containing current cygdrive prefix?

> - /proc/partitions now prints the windows mount points the device is mounted
>   on.  This allows to recognize the underlying Windows devices of the Cygwin
>   raw device names.

$ cat /proc/partitions
major minor  #blocks  name   win-mounts

    8     0  78150744 sda
    8     1  78149688 sda1   C:\dev\sdb1\
    8    16  78150744 sdb
    8    17    102400 sdb1
    8    18    131072 sdb2
    8    19  77916160 sdb3   C:\
    8    32 488386584 sdc
    8    33 486615520 sdc1   C:\dev\sdb1\dev\sdc1\ C:\dev\sdb1\d\ C:\dev\sdc1\
    8    48 312571224 sdd
    8    49 312568641 sdd1   C:\dev\sdb1\dev\sdd1\ C:\dev\sdd1\
    8    64         0 sde
    8    80         0 sdf
    8    96         0 sdg
    8   112         0 sdh

I approve of this product and/or service.
I would use a mountvol data around here somewhere, too. But it's useful as it
is already.

> - New API: quotactl, designed after the Linux/BSD function, but severly
severely? I'm no expert, but that's probably the right form.

A slightly unrelated request, but... I just had an issue I could prevent if
applying brain to hands, but... would it be a feasible request to make the
output of 'uname -r' suitable for naming a file?


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 24.10.2014, <19:51>

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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Keith Christian]

Here's a function for you Andrey, in appreciation for all the work you
contribute to Cygwin:


type uname_r
uname_r is a function


uname_r ()
{
    uname -r | sed -e 's/[.(/\)]/_/g' | sed -e 's/\(.*\)\(_$\)/\1/'
}


uname_r
1_7_32_0_274_5_3



On Fri, Oct 24, 2014 at 10:20 AM, Andrey Repin <anrdaemon@yandex.ru> wrote:
> Greetings, Corinna Vinschen!
>
>> For your convenience I wrote new documentation.  Since this is a TEST
>> prerelease, the new documentation is not part of the official docs yet.
>> Rather have a look at
>
>>   https://cygwin.com/preliminary-ntsec.html
>
> "via an undocumented APIr " should be "... API, " probably.
>
>> If you read it
>> (which I seriously hope for) and it's all just incomprehensible
>> gobbledygook to you, please say so on the mailing list
>
>>   cygwin AT cygwin DOT com
>
>> so we have a chance to improve the documentation.
>
> I'm in the process of reading it. Goes slowly, but that's due to my head
> condition. It really a very good read, thank you.
>
>> - /proc/cygdrive is a new symlink pointing to the current cygdrive prefix.
>>   This can be utilized in scripts to access paths via cygdrive prefix, even
>>   if the cygdrive prefix has been changed by the user.
>
> Hm. The prefix currently set to just "/".
>
> $ ls -l /proc/cygdrive
> lrwxrwxrwx 1 anrdaemon None 0 Oct 24 20:17 /proc/cygdrive -> /proc/cygdrive
>
> $ ls -l /proc/cygdrive/
> ls: cannot access /proc/cygdrive/: Not a directory
>
> Is this... normal?
> Or what this is supposed to be at all? Shouldn't it be a simple text file
> containing current cygdrive prefix?
>
>> - /proc/partitions now prints the windows mount points the device is mounted
>>   on.  This allows to recognize the underlying Windows devices of the Cygwin
>>   raw device names.
>
> $ cat /proc/partitions
> major minor  #blocks  name   win-mounts
>
>     8     0  78150744 sda
>     8     1  78149688 sda1   C:\dev\sdb1\
>     8    16  78150744 sdb
>     8    17    102400 sdb1
>     8    18    131072 sdb2
>     8    19  77916160 sdb3   C:\
>     8    32 488386584 sdc
>     8    33 486615520 sdc1   C:\dev\sdb1\dev\sdc1\ C:\dev\sdb1\d\ C:\dev\sdc1\
>     8    48 312571224 sdd
>     8    49 312568641 sdd1   C:\dev\sdb1\dev\sdd1\ C:\dev\sdd1\
>     8    64         0 sde
>     8    80         0 sdf
>     8    96         0 sdg
>     8   112         0 sdh
>
> I approve of this product and/or service.
> I would use a mountvol data around here somewhere, too. But it's useful as it
> is already.
>
>> - New API: quotactl, designed after the Linux/BSD function, but severly
> severely? I'm no expert, but that's probably the right form.
>
> A slightly unrelated request, but... I just had an issue I could prevent if
> applying brain to hands, but... would it be a feasible request to make the
> output of 'uname -r' suitable for naming a file?
>
>
> --
> WBR,
> Andrey Repin (anrdaemon@yandex.ru) 24.10.2014, <19:51>
>
> 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
>

--
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] TEST RELEASE: Cygwin 1.7.33-0.1

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 357 bytes --]

On 10/24/2014 11:28 AM, Keith Christian wrote:
> uname_r ()
> {
>     uname -r | sed -e 's/[.(/\)]/_/g' | sed -e 's/\(.*\)\(_$\)/\1/'
> }

Or for one less fork and less typing:

uname_r ()
{
  uname -r | sed 's/[.(/\)]/_/g; s/_$//'
}

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Keith Christian]

Thank you, Eric.  Will have to remember the semicolon to combine two
sed commands vs. trying to use "-e" which did not ever work properly
for me.  I knew there must have been a better way to combine sed
commands!

On Fri, Oct 24, 2014 at 11:57 AM, Eric Blake <eblake@redhat.com> wrote:
> On 10/24/2014 11:28 AM, Keith Christian wrote:
>> uname_r ()
>> {
>>     uname -r | sed -e 's/[.(/\)]/_/g' | sed -e 's/\(.*\)\(_$\)/\1/'
>> }
>
> Or for one less fork and less typing:
>
> uname_r ()
> {
>   uname -r | sed 's/[.(/\)]/_/g; s/_$//'
> }
>
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://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

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Thomas Wolff]

Am 24.10.2014 19:28, schrieb Keith Christian:
> Here's a function for you Andrey, in appreciation for all the work you
> contribute to Cygwin:
>
>
> type uname_r
> uname_r is a function
>
>
> uname_r ()
> {
>      uname -r | sed -e 's/[.(/\)]/_/g' | sed -e 's/\(.*\)\(_$\)/\1/'
> }
>
>
> uname_r
> 1_7_32_0_274_5_3
How about:
function uname-r () {
     uname -r|sed -e 's,(,-,' -e 's,/,_,g' -e 's,),,'
}
uname-r
1.7.33-0.278_5_3


--
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] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2781 bytes --]

On Oct 24 20:20, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> > For your convenience I wrote new documentation.  Since this is a TEST
> > prerelease, the new documentation is not part of the official docs yet.
> > Rather have a look at
> 
> >   https://cygwin.com/preliminary-ntsec.html
> 
> "via an undocumented APIr " should be "... API, " probably.

Thanks, fixed.

> > If you read it
> > (which I seriously hope for) and it's all just incomprehensible
> > gobbledygook to you, please say so on the mailing list
> 
> >   cygwin AT cygwin DOT com
> 
> > so we have a chance to improve the documentation.
> 
> I'm in the process of reading it. Goes slowly, but that's due to my head
> condition. It really a very good read, thank you.

Thanks, I'm glad to read that.

> > - /proc/cygdrive is a new symlink pointing to the current cygdrive prefix.
> >   This can be utilized in scripts to access paths via cygdrive prefix, even
> >   if the cygdrive prefix has been changed by the user.
> 
> Hm. The prefix currently set to just "/".
> 
> $ ls -l /proc/cygdrive
> lrwxrwxrwx 1 anrdaemon None 0 Oct 24 20:17 /proc/cygdrive -> /proc/cygdrive
> 
> $ ls -l /proc/cygdrive/
> ls: cannot access /proc/cygdrive/: Not a directory
> 
> Is this... normal?

No, it's a bug.  The internal cygdrive path has a trailing slash, which
I have to remove for the symlink.  If the cygdrive path is "/", the
result is an empty path, which is the same as a self-reference.  I fixed
that in CVS.

> Or what this is supposed to be at all? Shouldn't it be a simple text file
> containing current cygdrive prefix?

As a symlink, you can use /proc/cygdrive directly as path component
in a script.  With a text file you couldn't do that.

> > - /proc/partitions now prints the windows mount points the device is mounted
> >   on.  This allows to recognize the underlying Windows devices of the Cygwin
> >   raw device names.
> [...]
> I approve of this product and/or service.
> I would use a mountvol data around here somewhere, too. But it's useful as it
> is already.

mountvol data?!?  -v?

> > - New API: quotactl, designed after the Linux/BSD function, but severly
> severely? I'm no expert, but that's probably the right form.

Thanks, fixed.

> A slightly unrelated request, but... I just had an issue I could prevent if
> applying brain to hands, but... would it be a feasible request to make the
> output of 'uname -r' suitable for naming a file?

I wouldn't do that.  The layout is checked by existing scripts.  I wouldn't
want to break that.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Angelo Graziosi]

Corinna Vinschen wrote:
> The major change in this new release is the new method to read account
> (passwd and group) information from the Windows user databases directly,
> without the requirement to generate /etc/passwd and /etc/group files to
> generate Unix-like uid and gid.

Does it mean that the users with /etc/{passwd,group} files have to 
rename them [*] before its installation TO TEST the new functionality?

Thanks,
  Angelo.

---
E.g. : "mv /etc/{passwd, group} /etc/{passwd-save, group-save}"

--
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] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

On Oct 22 14:07, Angelo Graziosi wrote:
> Corinna Vinschen wrote:
> >The major change in this new release is the new method to read account
> >(passwd and group) information from the Windows user databases directly,
> >without the requirement to generate /etc/passwd and /etc/group files to
> >generate Unix-like uid and gid.
> 
> Does it mean that the users with /etc/{passwd,group} files have to rename
> them [*] before its installation TO TEST the new functionality?

By default, Cygwin will use the file content, and fallback to requesting
account info from Windows if an account is missing in pasdswd or group.

As an example, just try `id':

$ id
uid=1049577(corinna) gid=1049701(vinschen) groups=1049701(vinschen),545(Users),14(REMOTE INTERACTIVE LOGON),4(INTERACTIVE),11(Authenticated Users),15(This Organization),4095(CurrentSession),66048(LOCAL),1049713(hirmke),1049089(Domain Users),1049148(Denied RODC Password Replication Group),401408(Medium Mandatory Level)

Remoing the files is one way to test, but it's the more awkward one.
The better way is to create an /etc/nsswitch.conf file with the
following content, and then stop your Cygwin shell and restart it:

$ cat > /etc/nsswitch.conf <<EOF
passwd: db
group: db
EOF
$ exit

For the details, see the new documentation, please.

It's really, really worth to read it!

It also explains the above, see

https://cygwin.com/preliminary-ntsec.html#ntsec-mapping
https://cygwin.com/preliminary-ntsec.html#ntsec-mapping-nsswitch


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Angelo Graziosi]

Corinna Vinschen wrote:
> As an example, just try `id':
>
> $ id
> uid=1049577(corinna) gid=1049701(vinschen) groups=1049701(vinschen),545(Users),

Here it prints:

uid=197609(angelo) gid=197121(None) gruppi=197121(None), 
197608(HomeUsers), 545(Users),

and many files are listed ad "angelo None",

-rw-r--r--  1 angelo None 8222906 22 set 16.12 14-007r2.pdf
-rw-r--r--  1 angelo None  354744 15 ott 13.43 ...

in your case, if I understand, you should have something like this

-rw-r--r--  1 corinna vinschen 8222906 22 set 16.12 14-007r2.pdf
-rw-r--r--  1 corinna vinschen 354744 15 ott 13.43 ...

instead... more interesting..

> For the details, see the new documentation, please.

yes, it will take a bit of time (mainly to understand... ;-))


Ciao and thanks,
  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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.1

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

On Oct 22 15:27, Angelo Graziosi wrote:
> Corinna Vinschen wrote:
> >As an example, just try `id':
> >
> >$ id
> >uid=1049577(corinna) gid=1049701(vinschen) groups=1049701(vinschen),545(Users),
> 
> Here it prints:
> 
> uid=197609(angelo) gid=197121(None) gruppi=197121(None), 197608(HomeUsers),
> 545(Users),
> 
> and many files are listed ad "angelo None",
> 
> -rw-r--r--  1 angelo None 8222906 22 set 16.12 14-007r2.pdf
> -rw-r--r--  1 angelo None  354744 15 ott 13.43 ...

Correct.  "None" is the name of the default group of local, non-domain
accounts on Windows.  This should be documented in the new documentation
as well, including the "how to tweak".

> in your case, if I understand, you should have something like this
> 
> -rw-r--r--  1 corinna vinschen 8222906 22 set 16.12 14-007r2.pdf
> -rw-r--r--  1 corinna vinschen 354744 15 ott 13.43 ...
> 
> instead... more interesting..
> 
> >For the details, see the new documentation, please.
> 
> yes, it will take a bit of time (mainly to understand... ;-))

Agreed.  Windows account handling and security stuff isn't easy anyway.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]