[ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7

[ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7

[Corinna Vinschen]

Hi folks,


I uploaded a new Cygwin test release 3.0.0-0.7

This release comes with a couple of new features and some interesting
bug fixes.

It also changes the output of uname(2) for newly built applications.
Applications built so far (that includes uname(1) from coreutils)
will still print the old uname output.  The new format allows for longer
strings.  Compare:

Old uname content:

  sysname:  CYGWIN_NT-10.0     or  CYGWIN_NT-10.0-WOW   on WOW64
  release:  3.0.0(0.335/5/3)   or  3.0.0s(0.335/5/3)    for snapshots
  version:  2019-01-29 19:23   Local build time 

Upcoming new uname content:

  sysname:  CYGWIN_NT-10.0-17763   or  CYGWIN_NT-10.0-17763-WOW64
  release:  3.0.0-335.x86_64       or  3.0.0-335.x86_64.snap
  version:  2019-01-29 19:23 UTC   Build time in UTC


Changes from 3.0.0-0.6:

- Fix three bugs in new /proc/PID/fd/DESCRIPTOR code allowing to
  reopen a file by using the existing handle.  These broke, for
  instance, `bash$ echo abc > >(cat)'


Please test.

=======================================================================

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

- Support for CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE,
  CLOCK_MONOTONIC_RAW, CLOCK_BOOTTIME, CLOCK_REALTIME_ALARM,
  CLOCK_BOOTTIME_ALARM clocks.

- Support for case sensitive directories.  mkdir(2) automatically
  creates directories within the Cygwin installation dir as case
  sensitive now.

  This feature requires Windows 10 1803 or later and WSL installed!

- New file ioctls's FS_IOC_GETFLAGS and FS_IOC_SETFLAGS.  The actual
  inode flags are Cygwin-specific.  This allows to set or reset
  DOS attributes, file sparseness, FS level encryption and compression,
  as well as directory case sensitivity programatically.

- New tools chattr(1) and lsattr(1) to utilize setting and viewing the
  aforementioned new ioctl's on the command line.

- Support for exFAT.

- Support Linux-specific open(2) flag O_PATH.

- Support Linux-specific linkat(2) flag AT_EMPTY_PATH.

- Support overrun counter for posix timers (via timer_getoverrun() or
  siginfo_t::si_overrun).

- New APIs: signalfd, timerfd_create, timerfd_gettime, timerfd_settime,
  timer_getoverrun.


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

- clock_nanosleep, pthread_condattr_setclock and timer_create now support
  all clocks, except CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID.

- clock_setres is a no-op now.

- Use the new POSIX unlink semantics on NTFS starting with Windows 10 1709.
  Deleting an in-use file now actually removes the file, rather than moving
  it to the recycler bin.

- Use the new POSIX rename semantics on NTFS starting with Windows 10 1809.
  Renaming a file to another in-use file now actually removes the other file,
  rather than moving it to the recycler bin.

- open(..., O_TMPFILE) now moves the file to the trash bin immediately,
  to free the parent directory.

- Wctype functions updated to Unicode 11.0.

- Remove matherr, and SVID and X/Open math library configurations.
  Default math library configuration is now IEEE.

- Improve uname(2) for newly built applications.

- Kerberos/MSV1_0 S4U authentication replaces two old methods:
  Creating a token from scratch and Cygwin LSA authentication package.

- Cygwin PIDs have been decoupled from Windows PID.  Cygwin PIDs are
  now incrementally dealt in the range from 2 up to 65535, POSIX-like.
  Native Windows processes not started by Cygwin processes are mapped
  into the range beyond 65535.


Bug Fixes
---------

- Fix a thread race when initializing CLOCK_MONOTONIC.
  Addresses: https://cygwin.com/ml/cygwin/2018-11/msg00017.html

- Fix early timeout from pthread_cond_timedwait.
  Addresses: https://cygwin.com/ml/cygwin/2018-11/msg00171.html

- Fix a bug in recognizing remote FAT/FAT32/exFAT correctly.

- Allow open(2)/stat(2)/linkat(2) of a file via /proc/PID/fd/DESCRIPTOR
  even if file has been deleted.
  Addresses: https://cygwin.com/ml/cygwin/2018-12/msg00125.html
             https://cygwin.com/ml/cygwin/2018-12/msg00028.html

- Fix a bug in select(2) when polling HANDLE-less descriptors.

- Fix WEOF handling in wctype functions.
  Addresses: https://cygwin.com/ml/cygwin/2018-12/msg00173.html

- Fix thread names in GDB when cygthreads get reused.

- Fix return value of gethostname in a border case.

- Disallow seteuid on disabled or locked out accounts.
  Addresses: https://cygwin.com/ml/cygwin/2019-01/msg00197.html

- Fix raise to work as required by POSIX.
  Addresses: https://cygwin.com/ml/cygwin/2019-01/msg00149.html

- Fix exception handling in pthreads.
  Addresses: https://cygwin.com/ml/cygwin/2019-01/msg00149.html

=======================================================================


Have fun,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

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

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7

[Michael Haubenwallner]

On 2/5/19 4:18 PM, Corinna Vinschen wrote:
> Hi folks,
> 
> 
> I uploaded a new Cygwin test release 3.0.0-0.7
> 

> Please test.
> 

There's another regression - regarding spawn, exec and waitpid,
loosing the exitstatus somewhere in between:

$ cat > dospawn.c <<EOF
#include <sys/types.h>
#include <sys/wait.h>
#include <process.h>
#include <stdio.h>

int main(int argc, char const **argv)
{
  if (argc > 1)
    {   
      int pid = spawnv(_P_NOWAITO, argv[1], &argv[1]);
      if (pid) 
        {
          int status = 0;
          pid_t wpid = waitpid(pid, &status, 0);
          if (wpid > 0)
            {
              printf("waitpid: pid %d status 0x%x\n", pid, status); 
              if (WIFEXITED(status))
                {
                  int ret = WEXITSTATUS(status);
                  return ret;
                }
            }
        }
    }   
  return 127;
}
EOF

$ gcc dospawn.c -o dospawn
$ ./dospawn /bin/bash -c /bin/false
waitpid: pid 123 status 0x0        <= 2.11.2 does provide status 0x100 as expected
$ echo $?
0        <= Actually I do expect the exit status of /bin/false to show up here.

It is important to have the exec() in between:
$ ./dospawn /bin/false
waitpid: pid 123 status 0x100
$ echo $?
1

Note that bash does detect it can simply exec("/bin/false"). With more complex
commands bash does not just exec():

$ ./dospawn /bin/bash -c ':; /bin/false'
waitpid: pid 123 status 0x100
$ echo $?
1

/haubi/

--
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: Cygwin 3.0.0-0.7

[Corinna Vinschen]

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

On Feb  7 17:14, Michael Haubenwallner wrote:
> On 2/5/19 4:18 PM, Corinna Vinschen wrote:
> > Hi folks,
> > 
> > 
> > I uploaded a new Cygwin test release 3.0.0-0.7
> > 
> 
> > Please test.
> > 
> 
> There's another regression - regarding spawn, exec and waitpid,
> loosing the exitstatus somewhere in between:
> 
> $ cat > dospawn.c <<EOF
> #include <sys/types.h>
> #include <sys/wait.h>
> #include <process.h>
> #include <stdio.h>
> 
> int main(int argc, char const **argv)
> {
>   if (argc > 1)
>     {   
>       int pid = spawnv(_P_NOWAITO, argv[1], &argv[1]);
>       if (pid) 
>         {
>           int status = 0;
>           pid_t wpid = waitpid(pid, &status, 0);
>           if (wpid > 0)
>             {
>               printf("waitpid: pid %d status 0x%x\n", pid, status); 
>               if (WIFEXITED(status))
>                 {
>                   int ret = WEXITSTATUS(status);
>                   return ret;
>                 }
>             }
>         }
>     }   
>   return 127;
> }
> EOF
> 
> $ gcc dospawn.c -o dospawn
> $ ./dospawn /bin/bash -c /bin/false
> waitpid: pid 123 status 0x0        <= 2.11.2 does provide status 0x100 as expected
> $ echo $?
> 0        <= Actually I do expect the exit status of /bin/false to show up here.
> 

Any chance you could take a look?  I haven't much time for Cygwin the
next couple of days.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7

[Michael Haubenwallner]

On 2/7/19 7:27 PM, Corinna Vinschen wrote:
> On Feb  7 17:14, Michael Haubenwallner wrote:
>> On 2/5/19 4:18 PM, Corinna Vinschen wrote:
>>> Hi folks,
>>>
>>>
>>> I uploaded a new Cygwin test release 3.0.0-0.7
>>>
>>
>>> Please test.
>>>
>>
>> There's another regression - regarding spawn, exec and waitpid,
>> loosing the exitstatus somewhere in between:
>>
> 
> Any chance you could take a look?  I haven't much time for Cygwin the
> next couple of days.

Ok, will do. Any hints probably?

/haubi/

--
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: Cygwin 3.0.0-0.7

[Corinna Vinschen]

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

On Feb  8 07:46, Michael Haubenwallner wrote:
> 
> On 2/7/19 7:27 PM, Corinna Vinschen wrote:
> > On Feb  7 17:14, Michael Haubenwallner wrote:
> >> On 2/5/19 4:18 PM, Corinna Vinschen wrote:
> >>> Hi folks,
> >>>
> >>>
> >>> I uploaded a new Cygwin test release 3.0.0-0.7
> >>>
> >>
> >>> Please test.
> >>>
> >>
> >> There's another regression - regarding spawn, exec and waitpid,
> >> loosing the exitstatus somewhere in between:
> >>
> > 
> > Any chance you could take a look?  I haven't much time for Cygwin the
> > next couple of days.
> 
> Ok, will do. Any hints probably?

Thanks!  The only thing coming to mind is the removal of the parent
handle when switching PID method.  Or maybe the permission restriction
on the process handles?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7

[Michael Haubenwallner]

On 2/8/19 12:31 PM, Corinna Vinschen wrote:
> On Feb  8 07:46, Michael Haubenwallner wrote:
>>
>> On 2/7/19 7:27 PM, Corinna Vinschen wrote:
>>> On Feb  7 17:14, Michael Haubenwallner wrote:
>>>> On 2/5/19 4:18 PM, Corinna Vinschen wrote:
>>>>> Hi folks,
>>>>>
>>>>>
>>>>> I uploaded a new Cygwin test release 3.0.0-0.7
>>>>>
>>>>
>>>>> Please test.
>>>>>
>>>>
>>>> There's another regression - regarding spawn, exec and waitpid,
>>>> loosing the exitstatus somewhere in between:
>>>>
>>>
>>> Any chance you could take a look?  I haven't much time for Cygwin the
>>> next couple of days.
>>
>> Ok, will do. Any hints probably?
> 
> Thanks!  The only thing coming to mind is the removal of the parent
> handle when switching PID method.  Or maybe the permission restriction
> on the process handles?

For now it seems like there's an inconsistency with PIDs:
A first process PID 100, receives PID 101 from spawn(),
but in the new process getpid() returns 102:

$ ./dospawn /bin/bash -c 'echo $$'
12625
waitpid: pid 12624 status 0x0

/haubi/

--
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: Cygwin 3.0.0-0.7

[Corinna Vinschen]

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

On Feb  8 12:51, Michael Haubenwallner wrote:
> 
> 
> On 2/8/19 12:31 PM, Corinna Vinschen wrote:
> > On Feb  8 07:46, Michael Haubenwallner wrote:
> >>
> >> On 2/7/19 7:27 PM, Corinna Vinschen wrote:
> >>> On Feb  7 17:14, Michael Haubenwallner wrote:
> >>>> On 2/5/19 4:18 PM, Corinna Vinschen wrote:
> >>>>> Hi folks,
> >>>>>
> >>>>>
> >>>>> I uploaded a new Cygwin test release 3.0.0-0.7
> >>>>>
> >>>>
> >>>>> Please test.
> >>>>>
> >>>>
> >>>> There's another regression - regarding spawn, exec and waitpid,
> >>>> loosing the exitstatus somewhere in between:
> >>>>
> >>>
> >>> Any chance you could take a look?  I haven't much time for Cygwin the
> >>> next couple of days.
> >>
> >> Ok, will do. Any hints probably?
> > 
> > Thanks!  The only thing coming to mind is the removal of the parent
> > handle when switching PID method.  Or maybe the permission restriction
> > on the process handles?
> 
> For now it seems like there's an inconsistency with PIDs:
> A first process PID 100, receives PID 101 from spawn(),
> but in the new process getpid() returns 102:
> 
> $ ./dospawn /bin/bash -c 'echo $$'
> 12625
> waitpid: pid 12624 status 0x0

Oh, hmm.  If you call spawnve, rather than execve, a new child pid
is generated in spawnve, rather than just keeping the callers pid.

However, apparently the child invents its own pid in pinfo::thisproc
after being spawned.  But actually this should only occur for forked
processes aore processes started from non-Cygwin parents.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7

[Corinna Vinschen]

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

On Feb  8 13:21, Corinna Vinschen wrote:
> On Feb  8 12:51, Michael Haubenwallner wrote:
> > 
> > 
> > On 2/8/19 12:31 PM, Corinna Vinschen wrote:
> > > On Feb  8 07:46, Michael Haubenwallner wrote:
> > >>
> > >> On 2/7/19 7:27 PM, Corinna Vinschen wrote:
> > >>> On Feb  7 17:14, Michael Haubenwallner wrote:
> > >>>> On 2/5/19 4:18 PM, Corinna Vinschen wrote:
> > >>>>> Hi folks,
> > >>>>>
> > >>>>>
> > >>>>> I uploaded a new Cygwin test release 3.0.0-0.7
> > >>>>>
> > >>>>
> > >>>>> Please test.
> > >>>>>
> > >>>>
> > >>>> There's another regression - regarding spawn, exec and waitpid,
> > >>>> loosing the exitstatus somewhere in between:
> > >>>>
> > >>>
> > >>> Any chance you could take a look?  I haven't much time for Cygwin the
> > >>> next couple of days.
> > >>
> > >> Ok, will do. Any hints probably?
> > > 
> > > Thanks!  The only thing coming to mind is the removal of the parent
> > > handle when switching PID method.  Or maybe the permission restriction
> > > on the process handles?
> > 
> > For now it seems like there's an inconsistency with PIDs:
> > A first process PID 100, receives PID 101 from spawn(),
> > but in the new process getpid() returns 102:
> > 
> > $ ./dospawn /bin/bash -c 'echo $$'
> > 12625
> > waitpid: pid 12624 status 0x0
> 
> Oh, hmm.  If you call spawnve, rather than execve, a new child pid
> is generated in spawnve, rather than just keeping the callers pid.
> 
> However, apparently the child invents its own pid in pinfo::thisproc
> after being spawned.  But actually this should only occur for forked
> processes aore processes started from non-Cygwin parents.

Does that help, by any chance:

diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
index 78506d43de29..0b274287d9f6 100644
--- a/winsup/cygwin/dcrt0.cc
+++ b/winsup/cygwin/dcrt0.cc
@@ -656,7 +656,7 @@ child_info_spawn::handle_spawn ()
       !DuplicateHandle (GetCurrentProcess (), moreinfo->myself_pinfo,
 			GetCurrentProcess (), &h, 0,
 			FALSE, DUPLICATE_SAME_ACCESS | DUPLICATE_CLOSE_SOURCE))
-    h = NULL;
+    h = INVALID_HANDLE_VALUE;
 
   /* Setup our write end of the process pipe.  Clear the one in the structure.
      The destructor should never be called for this but, it can't hurt to be
diff --git a/winsup/cygwin/pinfo.cc b/winsup/cygwin/pinfo.cc
index 445bd35b224e..d10c4fc4580c 100644
--- a/winsup/cygwin/pinfo.cc
+++ b/winsup/cygwin/pinfo.cc
@@ -62,6 +62,8 @@ pinfo::thisproc (HANDLE h)
       cygheap->pid = create_cygwin_pid ();
       flags |= PID_NEW;
     }
+  else if (h == INVALID_HANDLE_VALUE)
+    h = NULL;
 
   init (cygheap->pid, flags, h);
   procinfo->process_state |= PID_IN_USE;


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7

[Michael Haubenwallner]

On 2/8/19 1:23 PM, Corinna Vinschen wrote:
> On Feb  8 13:21, Corinna Vinschen wrote:
>> On Feb  8 12:51, Michael Haubenwallner wrote:
>>>
>>> For now it seems like there's an inconsistency with PIDs:
>>> A first process PID 100, receives PID 101 from spawn(),
>>> but in the new process getpid() returns 102:
>>>
>>> $ ./dospawn /bin/bash -c 'echo $$'
>>> 12625
>>> waitpid: pid 12624 status 0x0
>>
>> Oh, hmm.  If you call spawnve, rather than execve, a new child pid
>> is generated in spawnve, rather than just keeping the callers pid.
>>
>> However, apparently the child invents its own pid in pinfo::thisproc
>> after being spawned.  But actually this should only occur for forked
>> processes aore processes started from non-Cygwin parents.
> 
> Does that help, by any chance:
> 
> diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
> index 78506d43de29..0b274287d9f6 100644
> --- a/winsup/cygwin/dcrt0.cc
> +++ b/winsup/cygwin/dcrt0.cc
> @@ -656,7 +656,7 @@ child_info_spawn::handle_spawn ()
>        !DuplicateHandle (GetCurrentProcess (), moreinfo->myself_pinfo,
>  			GetCurrentProcess (), &h, 0,
>  			FALSE, DUPLICATE_SAME_ACCESS | DUPLICATE_CLOSE_SOURCE))
> -    h = NULL;
> +    h = INVALID_HANDLE_VALUE;
>  
>    /* Setup our write end of the process pipe.  Clear the one in the structure.
>       The destructor should never be called for this but, it can't hurt to be
> diff --git a/winsup/cygwin/pinfo.cc b/winsup/cygwin/pinfo.cc
> index 445bd35b224e..d10c4fc4580c 100644
> --- a/winsup/cygwin/pinfo.cc
> +++ b/winsup/cygwin/pinfo.cc
> @@ -62,6 +62,8 @@ pinfo::thisproc (HANDLE h)
>        cygheap->pid = create_cygwin_pid ();
>        flags |= PID_NEW;
>      }
> +  else if (h == INVALID_HANDLE_VALUE)
> +    h = NULL;

No, because cygheap->pid still is the parent's pid here, not the new child's one.

How should the child be informed at all about the new cygpid value generated in
parent's child_info_spawn::worker() ?

/haubi/

--
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: Cygwin 3.0.0-0.7

[Corinna Vinschen]

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

On Feb  8 13:52, Michael Haubenwallner wrote:
> 
> 
> On 2/8/19 1:23 PM, Corinna Vinschen wrote:
> > On Feb  8 13:21, Corinna Vinschen wrote:
> >> On Feb  8 12:51, Michael Haubenwallner wrote:
> >>>
> >>> For now it seems like there's an inconsistency with PIDs:
> >>> A first process PID 100, receives PID 101 from spawn(),
> >>> but in the new process getpid() returns 102:
> >>>
> >>> $ ./dospawn /bin/bash -c 'echo $$'
> >>> 12625
> >>> waitpid: pid 12624 status 0x0
> >>
> >> Oh, hmm.  If you call spawnve, rather than execve, a new child pid
> >> is generated in spawnve, rather than just keeping the callers pid.
> >>
> >> However, apparently the child invents its own pid in pinfo::thisproc
> >> after being spawned.  But actually this should only occur for forked
> >> processes aore processes started from non-Cygwin parents.
> > 
> > Does that help, by any chance:
> > 
> > diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
> > index 78506d43de29..0b274287d9f6 100644
> > --- a/winsup/cygwin/dcrt0.cc
> > +++ b/winsup/cygwin/dcrt0.cc
> > @@ -656,7 +656,7 @@ child_info_spawn::handle_spawn ()
> >        !DuplicateHandle (GetCurrentProcess (), moreinfo->myself_pinfo,
> >  			GetCurrentProcess (), &h, 0,
> >  			FALSE, DUPLICATE_SAME_ACCESS | DUPLICATE_CLOSE_SOURCE))
> > -    h = NULL;
> > +    h = INVALID_HANDLE_VALUE;
> >  
> >    /* Setup our write end of the process pipe.  Clear the one in the structure.
> >       The destructor should never be called for this but, it can't hurt to be
> > diff --git a/winsup/cygwin/pinfo.cc b/winsup/cygwin/pinfo.cc
> > index 445bd35b224e..d10c4fc4580c 100644
> > --- a/winsup/cygwin/pinfo.cc
> > +++ b/winsup/cygwin/pinfo.cc
> > @@ -62,6 +62,8 @@ pinfo::thisproc (HANDLE h)
> >        cygheap->pid = create_cygwin_pid ();
> >        flags |= PID_NEW;
> >      }
> > +  else if (h == INVALID_HANDLE_VALUE)
> > +    h = NULL;
> 
> No, because cygheap->pid still is the parent's pid here, not the new child's one.
> 
> How should the child be informed at all about the new cygpid value generated in
> parent's child_info_spawn::worker() ?

I just realized this myself.  The old method creating Cygwin pids just
fetched the pid from GetCurrentProcessId(), which was right for spawned
(but not execed) processes.  For the new pid we might have to give this
to the child via child_info_spawn.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7

[Corinna Vinschen]

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

On Feb  8 14:06, Corinna Vinschen wrote:
> On Feb  8 13:52, Michael Haubenwallner wrote:
> > On 2/8/19 1:23 PM, Corinna Vinschen wrote:
> > > On Feb  8 13:21, Corinna Vinschen wrote:
> > >> On Feb  8 12:51, Michael Haubenwallner wrote:
> > >>>
> > >>> For now it seems like there's an inconsistency with PIDs:
> > >>> A first process PID 100, receives PID 101 from spawn(),
> > >>> but in the new process getpid() returns 102:
> > >>>
> > >>> $ ./dospawn /bin/bash -c 'echo $$'
> > >>> 12625
> > >>> waitpid: pid 12624 status 0x0
> > >>
> > >> Oh, hmm.  If you call spawnve, rather than execve, a new child pid
> > >> is generated in spawnve, rather than just keeping the callers pid.
> > >>
> > >> However, apparently the child invents its own pid in pinfo::thisproc
> > >> after being spawned.  But actually this should only occur for forked
> > >> processes aore processes started from non-Cygwin parents.
> > > 
> > > Does that help, by any chance:
> > > [nope]
> > 
> > How should the child be informed at all about the new cygpid value generated in
> > parent's child_info_spawn::worker() ?
> 
> I just realized this myself.  The old method creating Cygwin pids just
> fetched the pid from GetCurrentProcessId(), which was right for spawned
> (but not execed) processes.  For the new pid we might have to give this
> to the child via child_info_spawn.

This works for me, can you test this, too, please?

diff --git a/winsup/cygwin/child_info.h b/winsup/cygwin/child_info.h
index 67264119eae9..847614ff299a 100644
--- a/winsup/cygwin/child_info.h
+++ b/winsup/cygwin/child_info.h
@@ -144,6 +144,7 @@ class child_info_spawn: public child_info
 {
   HANDLE hExeced;
   HANDLE ev;
+  pid_t cygpid;
 public:
   cygheap_exec_info *moreinfo;
   int __stdin;
diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
index 78506d43de29..11edcdf0d21b 100644
--- a/winsup/cygwin/dcrt0.cc
+++ b/winsup/cygwin/dcrt0.cc
@@ -652,11 +652,16 @@ child_info_spawn::handle_spawn ()
 	cygheap_fixup_in_child (true);
 	memory_init ();
       }
+
+  cygheap->pid = cygpid;
+
+  /* Spawned process sets h to INVALID_HANDLE_VALUE to notify
+     pinfo::thisproc not to create another pid. */
   if (!moreinfo->myself_pinfo ||
       !DuplicateHandle (GetCurrentProcess (), moreinfo->myself_pinfo,
 			GetCurrentProcess (), &h, 0,
 			FALSE, DUPLICATE_SAME_ACCESS | DUPLICATE_CLOSE_SOURCE))
-    h = NULL;
+    h = (type == _CH_SPAWN) ? INVALID_HANDLE_VALUE : NULL;
 
   /* Setup our write end of the process pipe.  Clear the one in the structure.
      The destructor should never be called for this but, it can't hurt to be
diff --git a/winsup/cygwin/pinfo.cc b/winsup/cygwin/pinfo.cc
index 445bd35b224e..61fbc9bc19bf 100644
--- a/winsup/cygwin/pinfo.cc
+++ b/winsup/cygwin/pinfo.cc
@@ -57,11 +57,15 @@ pinfo::thisproc (HANDLE h)
   procinfo = NULL;
 
   DWORD flags = PID_IN_USE | PID_ACTIVE;
+  /* Forked process or process started from non-Cygwin parent needs a pid. */
   if (!h)
     {
       cygheap->pid = create_cygwin_pid ();
       flags |= PID_NEW;
     }
+  /* spawnve'd process got pid from parent. */
+  else if (h == INVALID_HANDLE_VALUE)
+    h = NULL;
 
   init (cygheap->pid, flags, h);
   procinfo->process_state |= PID_IN_USE;
diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc
index d969c66ea19a..ebc34d10542f 100644
--- a/winsup/cygwin/spawn.cc
+++ b/winsup/cygwin/spawn.cc
@@ -258,7 +258,6 @@ child_info_spawn::worker (const char *prog_arg, const char *const *argv,
 			  int in__stdin, int in__stdout)
 {
   bool rc;
-  pid_t cygpid;
   int res = -1;
 
   /* Check if we have been called from exec{lv}p or spawn{lv}p and mask
@@ -578,6 +577,8 @@ child_info_spawn::worker (const char *prog_arg, const char *const *argv,
       if (!real_path.iscygexec () && mode == _P_OVERLAY)
 	myself->process_state |= PID_NOTCYGWIN;
 
+      cygpid = (mode != _P_OVERLAY) ? create_cygwin_pid () : myself->pid;
+
       wchar_t wcmd[(size_t) cmd];
       if (!::cygheap->user.issetuid ()
 	  || (::cygheap->user.saved_uid == ::cygheap->user.real_uid
@@ -708,11 +709,6 @@ child_info_spawn::worker (const char *prog_arg, const char *const *argv,
       if (::cygheap->fdtab.need_fixup_before ())
 	::cygheap->fdtab.fixup_before_exec (pi.dwProcessId);
 
-      if (mode != _P_OVERLAY)
-	cygpid = create_cygwin_pid ();
-      else
-	cygpid = myself->pid;
-
       /* Print the original program name here so the user can see that too.  */
       syscall_printf ("pid %d, prog_arg %s, cmd line %.9500s)",
 		      rc ? cygpid : (unsigned int) -1, prog_arg, (const char *) cmd);


I pushed your forkable branch to master, btw.  Would you mind to do the
honors in the ;rease notes at cygwin/release/3.0 and doc/new-features.xml?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7

[Michael Haubenwallner]

On 2/8/19 2:28 PM, Corinna Vinschen wrote:
> On Feb  8 14:06, Corinna Vinschen wrote:
>> On Feb  8 13:52, Michael Haubenwallner wrote:
>>> On 2/8/19 1:23 PM, Corinna Vinschen wrote:
>>>> On Feb  8 13:21, Corinna Vinschen wrote:
>>>>> On Feb  8 12:51, Michael Haubenwallner wrote:
>>>>>>
>>>>>> For now it seems like there's an inconsistency with PIDs:
>>>>>> A first process PID 100, receives PID 101 from spawn(),
>>>>>> but in the new process getpid() returns 102:
>>>>>>
>>>>>> $ ./dospawn /bin/bash -c 'echo $$'
>>>>>> 12625
>>>>>> waitpid: pid 12624 status 0x0
>>>>>
>>>>> Oh, hmm.  If you call spawnve, rather than execve, a new child pid
>>>>> is generated in spawnve, rather than just keeping the callers pid.
>>>>>
>>>>> However, apparently the child invents its own pid in pinfo::thisproc
>>>>> after being spawned.  But actually this should only occur for forked
>>>>> processes aore processes started from non-Cygwin parents.
>>>>
>>>> Does that help, by any chance:
>>>> [nope]
>>>
>>> How should the child be informed at all about the new cygpid value generated in
>>> parent's child_info_spawn::worker() ?
>>
>> I just realized this myself.  The old method creating Cygwin pids just
>> fetched the pid from GetCurrentProcessId(), which was right for spawned
>> (but not execed) processes.  For the new pid we might have to give this
>> to the child via child_info_spawn.
> 
> This works for me, can you test this, too, please?

Looks good to me as well, I'm going to start my hours running use case now.

> 
> I pushed your forkable branch to master, btw.  Would you mind to do the
> honors in the ;rease notes at cygwin/release/3.0 and doc/new-features.xml?

Ok, just preparing the tests first. Thanks a lot!

/haubi/

--
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: Cygwin 3.0.0-0.7

[Corinna Vinschen]

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

On Feb  8 15:43, Michael Haubenwallner wrote:
> 
> 
> On 2/8/19 2:28 PM, Corinna Vinschen wrote:
> > On Feb  8 14:06, Corinna Vinschen wrote:
> >> On Feb  8 13:52, Michael Haubenwallner wrote:
> >>> On 2/8/19 1:23 PM, Corinna Vinschen wrote:
> >>>> On Feb  8 13:21, Corinna Vinschen wrote:
> >>>>> On Feb  8 12:51, Michael Haubenwallner wrote:
> >>>>>>
> >>>>>> For now it seems like there's an inconsistency with PIDs:
> >>>>>> A first process PID 100, receives PID 101 from spawn(),
> >>>>>> but in the new process getpid() returns 102:
> >>>>>>
> >>>>>> $ ./dospawn /bin/bash -c 'echo $$'
> >>>>>> 12625
> >>>>>> waitpid: pid 12624 status 0x0
> >>>>>
> >>>>> Oh, hmm.  If you call spawnve, rather than execve, a new child pid
> >>>>> is generated in spawnve, rather than just keeping the callers pid.
> >>>>>
> >>>>> However, apparently the child invents its own pid in pinfo::thisproc
> >>>>> after being spawned.  But actually this should only occur for forked
> >>>>> processes aore processes started from non-Cygwin parents.
> >>>>
> >>>> Does that help, by any chance:
> >>>> [nope]
> >>>
> >>> How should the child be informed at all about the new cygpid value generated in
> >>> parent's child_info_spawn::worker() ?
> >>
> >> I just realized this myself.  The old method creating Cygwin pids just
> >> fetched the pid from GetCurrentProcessId(), which was right for spawned
> >> (but not execed) processes.  For the new pid we might have to give this
> >> to the child via child_info_spawn.
> > 
> > This works for me, can you test this, too, please?
> 
> Looks good to me as well, I'm going to start my hours running use case now.

Sounds good, thanks.  I'll push this change now.  We can always
rework it if it's insufficient.

> > I pushed your forkable branch to master, btw.  Would you mind to do the
> > honors in the ;rease notes at cygwin/release/3.0 and doc/new-features.xml?
> 
> Ok, just preparing the tests first. Thanks a lot!

No worries, as long as I know you're here to answer questions ;)


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7

[Michael Haubenwallner]

On 2/8/19 3:48 PM, Corinna Vinschen wrote:
> On Feb  8 15:43, Michael Haubenwallner wrote:
>> On 2/8/19 2:28 PM, Corinna Vinschen wrote:
>>> On Feb  8 14:06, Corinna Vinschen wrote:
>>>> On Feb  8 13:52, Michael Haubenwallner wrote:
>>>>> On 2/8/19 1:23 PM, Corinna Vinschen wrote:
>>>>>> On Feb  8 13:21, Corinna Vinschen wrote:
>>>>>>> On Feb  8 12:51, Michael Haubenwallner wrote:
>>>>>>>>
>>>>>>>> For now it seems like there's an inconsistency with PIDs:
>>>>>>>> A first process PID 100, receives PID 101 from spawn(),
>>>>>>>> but in the new process getpid() returns 102:
>>>>>>>>
>>>>>>>> $ ./dospawn /bin/bash -c 'echo $$'
>>>>>>>> 12625
>>>>>>>> waitpid: pid 12624 status 0x0
>>>>>>>
>>>>>>> Oh, hmm.  If you call spawnve, rather than execve, a new child pid
>>>>>>> is generated in spawnve, rather than just keeping the callers pid.
>>>>>>>
>>>>>>> However, apparently the child invents its own pid in pinfo::thisproc
>>>>>>> after being spawned.  But actually this should only occur for forked
>>>>>>> processes aore processes started from non-Cygwin parents.
>>>>>>
>>>>>> Does that help, by any chance:
>>>>>> [nope]
>>>>>
>>>>> How should the child be informed at all about the new cygpid value generated in
>>>>> parent's child_info_spawn::worker() ?
>>>>
>>>> I just realized this myself.  The old method creating Cygwin pids just
>>>> fetched the pid from GetCurrentProcessId(), which was right for spawned
>>>> (but not execed) processes.  For the new pid we might have to give this
>>>> to the child via child_info_spawn.
>>>
>>> This works for me, can you test this, too, please?
>>
>> Looks good to me as well, I'm going to start my hours running use case now.
> 
> Sounds good, thanks.  I'll push this change now.  We can always
> rework it if it's insufficient.

*** WARNING WARNING WARNING WARNING WARNING ***
*** .../newlib-cygwin/winsup/cygwin/child_info.h: magic number for CHILD_INFO_MAGIC changed old 0x3ee00652U != new 0xf4531879U
*** WARNING WARNING WARNING WARNING WARNING ***

Seems like the CHILD_INFO_MAGIC bump is missing for this change, no?

/haubi/

--
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: Cygwin 3.0.0-0.7

[Michael Haubenwallner]

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


On 2/8/19 2:28 PM, Corinna Vinschen wrote:
> 
> I pushed your forkable branch to master, btw.  Would you mind to do the
> honors in the ;rease notes at cygwin/release/3.0 and doc/new-features.xml?

Do you mean like this?

/haubi/

[-- Attachment #2: 0001-forkables-add-release-notes.patch --]
[-- Type: text/x-patch, Size: 2443 bytes --]

From 0461e0a552caf0c58ab7999cfd2849c7180f7d30 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner <michael.haubenwallner@ssi-schaefer.com>
Date: Fri, 8 Feb 2019 15:38:56 +0100
Subject: [PATCH] forkables: add release notes

---
 winsup/cygwin/release/3.0   | 10 ++++++++++
 winsup/doc/new-features.xml | 12 ++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/winsup/cygwin/release/3.0 b/winsup/cygwin/release/3.0
index 4cd422a56..ef45e9f9d 100644
--- a/winsup/cygwin/release/3.0
+++ b/winsup/cygwin/release/3.0
@@ -66,6 +66,16 @@ What changed:
   Native Windows processes not started by Cygwin processes are mapped
   into the range beyond 65535.
 
+- Limited to executables and dlls located on the very same NTFS partition
+  as the Cygwin installation itself, and disabled by default, fork(2) now
+  is able to recover from when the executable or any dll required to load
+  into the new child process was removed or replaced since being loaded
+  into the parent process, or a dll with different content is found in the
+  parent process' current directory.  To enable this recovery feature, the
+  following command has to be executed once per Cygwin installation, with
+  subsequent shutdown of all Cygwin processes (or reboot), so the first
+  Cygwin process does find this directory existing:
+  $ mkdir --mode=a=rwxt /var/run/cygfork
 
 Bug Fixes
 ---------
diff --git a/winsup/doc/new-features.xml b/winsup/doc/new-features.xml
index 6801e3eeb..316a7446a 100644
--- a/winsup/doc/new-features.xml
+++ b/winsup/doc/new-features.xml
@@ -107,6 +107,18 @@ Native Windows processes not started by Cygwin processes are mapped
 into the range beyond 65535.
 </para></listitem>
 
+<listitem><para>
+Limited to executables and dlls located on the very same NTFS partition
+as the Cygwin installation itself, and disabled by default, fork(2) now
+is able to recover from when the executable or any dll required to load
+into the new child process was removed or replaced since being loaded
+into the parent process, or a dll with different content is found in the
+parent process' current directory.  To enable this recovery feature, the
+following command has to be executed once per Cygwin installation, with
+subsequent shutdown of all Cygwin processes (or reboot), so the first
+Cygwin process does find this directory existing:
+$ mkdir --mode=a=rwxt /var/run/cygfork
+</para></listitem>
 </itemizedlist>
 
 </sect2>
-- 
2.17.0



[-- Attachment #3: Type: text/plain, Size: 219 bytes --]


--
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: Cygwin 3.0.0-0.7

[Corinna Vinschen]

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

On Feb  8 17:17, Michael Haubenwallner wrote:
> 
> 
> On 2/8/19 3:48 PM, Corinna Vinschen wrote:
> > On Feb  8 15:43, Michael Haubenwallner wrote:
> >> On 2/8/19 2:28 PM, Corinna Vinschen wrote:
> >>> On Feb  8 14:06, Corinna Vinschen wrote:
> >>>> On Feb  8 13:52, Michael Haubenwallner wrote:
> >>>>> On 2/8/19 1:23 PM, Corinna Vinschen wrote:
> >>>>>> On Feb  8 13:21, Corinna Vinschen wrote:
> >>>>>>> On Feb  8 12:51, Michael Haubenwallner wrote:
> >>>>>>>>
> >>>>>>>> For now it seems like there's an inconsistency with PIDs:
> >>>>>>>> A first process PID 100, receives PID 101 from spawn(),
> >>>>>>>> but in the new process getpid() returns 102:
> >>>>>>>>
> >>>>>>>> $ ./dospawn /bin/bash -c 'echo $$'
> >>>>>>>> 12625
> >>>>>>>> waitpid: pid 12624 status 0x0
> >>>>>>>
> >>>>>>> Oh, hmm.  If you call spawnve, rather than execve, a new child pid
> >>>>>>> is generated in spawnve, rather than just keeping the callers pid.
> >>>>>>>
> >>>>>>> However, apparently the child invents its own pid in pinfo::thisproc
> >>>>>>> after being spawned.  But actually this should only occur for forked
> >>>>>>> processes aore processes started from non-Cygwin parents.
> >>>>>>
> >>>>>> Does that help, by any chance:
> >>>>>> [nope]
> >>>>>
> >>>>> How should the child be informed at all about the new cygpid value generated in
> >>>>> parent's child_info_spawn::worker() ?
> >>>>
> >>>> I just realized this myself.  The old method creating Cygwin pids just
> >>>> fetched the pid from GetCurrentProcessId(), which was right for spawned
> >>>> (but not execed) processes.  For the new pid we might have to give this
> >>>> to the child via child_info_spawn.
> >>>
> >>> This works for me, can you test this, too, please?
> >>
> >> Looks good to me as well, I'm going to start my hours running use case now.
> > 
> > Sounds good, thanks.  I'll push this change now.  We can always
> > rework it if it's insufficient.
> 
> *** WARNING WARNING WARNING WARNING WARNING ***
> *** .../newlib-cygwin/winsup/cygwin/child_info.h: magic number for CHILD_INFO_MAGIC changed old 0x3ee00652U != new 0xf4531879U
> *** WARNING WARNING WARNING WARNING WARNING ***
> 
> Seems like the CHILD_INFO_MAGIC bump is missing for this change, no?

Fixed.

Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7

[Corinna Vinschen]

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

On Feb  8 17:35, Michael Haubenwallner wrote:
> 
> On 2/8/19 2:28 PM, Corinna Vinschen wrote:
> > 
> > I pushed your forkable branch to master, btw.  Would you mind to do the
> > honors in the ;rease notes at cygwin/release/3.0 and doc/new-features.xml?
> 
> Do you mean like this?
> 
> /haubi/

> >From 0461e0a552caf0c58ab7999cfd2849c7180f7d30 Mon Sep 17 00:00:00 2001
> From: Michael Haubenwallner <michael.haubenwallner@ssi-schaefer.com>
> Date: Fri, 8 Feb 2019 15:38:56 +0100
> Subject: [PATCH] forkables: add release notes
> 
> ---
>  winsup/cygwin/release/3.0   | 10 ++++++++++
>  winsup/doc/new-features.xml | 12 ++++++++++++
>  2 files changed, 22 insertions(+)
> 
> diff --git a/winsup/cygwin/release/3.0 b/winsup/cygwin/release/3.0
> index 4cd422a56..ef45e9f9d 100644
> --- a/winsup/cygwin/release/3.0
> +++ b/winsup/cygwin/release/3.0
> @@ -66,6 +66,16 @@ What changed:
>    Native Windows processes not started by Cygwin processes are mapped
>    into the range beyond 65535.
>  
> +- Limited to executables and dlls located on the very same NTFS partition
> +  as the Cygwin installation itself, and disabled by default, fork(2) now
> +  is able to recover from when the executable or any dll required to load
> +  into the new child process was removed or replaced since being loaded
> +  into the parent process, or a dll with different content is found in the
> +  parent process' current directory.  To enable this recovery feature, the
> +  following command has to be executed once per Cygwin installation, with
> +  subsequent shutdown of all Cygwin processes (or reboot), so the first
> +  Cygwin process does find this directory existing:
> +  $ mkdir --mode=a=rwxt /var/run/cygfork

It's not bad but for release notes it's rather long.  Any chance to get
a more compact text?  Also, please add a "Cygwin: " prefix to the log
message summary.  I'd like to distinguish CYgwin-only changes from
newlib changes.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7

[Corinna Vinschen]

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

On Feb  8 17:58, Corinna Vinschen wrote:
> On Feb  8 17:35, Michael Haubenwallner wrote:
> > 
> > On 2/8/19 2:28 PM, Corinna Vinschen wrote:
> > > 
> > > I pushed your forkable branch to master, btw.  Would you mind to do the
> > > honors in the ;rease notes at cygwin/release/3.0 and doc/new-features.xml?
> > 
> > Do you mean like this?
> > 
> > /haubi/
> 
> > >From 0461e0a552caf0c58ab7999cfd2849c7180f7d30 Mon Sep 17 00:00:00 2001
> > From: Michael Haubenwallner <michael.haubenwallner@ssi-schaefer.com>
> > Date: Fri, 8 Feb 2019 15:38:56 +0100
> > Subject: [PATCH] forkables: add release notes
> > 
> > ---
> >  winsup/cygwin/release/3.0   | 10 ++++++++++
> >  winsup/doc/new-features.xml | 12 ++++++++++++
> >  2 files changed, 22 insertions(+)
> > 
> > diff --git a/winsup/cygwin/release/3.0 b/winsup/cygwin/release/3.0
> > index 4cd422a56..ef45e9f9d 100644
> > --- a/winsup/cygwin/release/3.0
> > +++ b/winsup/cygwin/release/3.0
> > @@ -66,6 +66,16 @@ What changed:
> >    Native Windows processes not started by Cygwin processes are mapped
> >    into the range beyond 65535.
> >  
> > +- Limited to executables and dlls located on the very same NTFS partition
> > +  as the Cygwin installation itself, and disabled by default, fork(2) now
> > +  is able to recover from when the executable or any dll required to load
> > +  into the new child process was removed or replaced since being loaded
> > +  into the parent process, or a dll with different content is found in the
> > +  parent process' current directory.  To enable this recovery feature, the
> > +  following command has to be executed once per Cygwin installation, with
> > +  subsequent shutdown of all Cygwin processes (or reboot), so the first
> > +  Cygwin process does find this directory existing:
> > +  $ mkdir --mode=a=rwxt /var/run/cygfork
> 
> It's not bad but for release notes it's rather long.  Any chance to get
> a more compact text?  Also, please add a "Cygwin: " prefix to the log
> message summary.  I'd like to distinguish CYgwin-only changes from
> newlib changes.

OTOH, if you want to extend the documentation, feel free...


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7

[Michael Haubenwallner]

[-- Attachment #1.1.1: Type: text/plain, Size: 793 bytes --]



On 2/8/19 6:00 PM, Corinna Vinschen wrote:
> On Feb  8 17:58, Corinna Vinschen wrote:
>> On Feb  8 17:35, Michael Haubenwallner wrote:
>>>
>>> On 2/8/19 2:28 PM, Corinna Vinschen wrote:
>>>>
>>>> I pushed your forkable branch to master, btw.  Would you mind to do the
>>>> honors in the ;rease notes at cygwin/release/3.0 and doc/new-features.xml?
>>>
>>> Do you mean like this?

>>
>> It's not bad but for release notes it's rather long.  Any chance to get
>> a more compact text?  Also, please add a "Cygwin: " prefix to the log
>> message summary.  I'd like to distinguish CYgwin-only changes from
>> newlib changes.
> 
> OTOH, if you want to extend the documentation, feel free...

Another try, with polish to already available doc around the forkables.

/haubi/

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: 0001-Cygwin-forkables-update-doc-add-release-notes.patch --]
[-- Type: text/x-patch; name="0001-Cygwin-forkables-update-doc-add-release-notes.patch", Size: 4818 bytes --]

From fc9911a188ba2ab8cb0e78c2820c56a5be1d16b8 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner <michael.haubenwallner@ssi-schaefer.com>
Date: Fri, 8 Feb 2019 15:38:56 +0100
Subject: [PATCH] Cygwin: forkables: update doc, add release notes

---
 winsup/cygwin/release/3.0   |  6 ++++++
 winsup/doc/highlights.xml   | 28 +++++++++++++++++-----------
 winsup/doc/new-features.xml |  7 +++++++
 3 files changed, 30 insertions(+), 11 deletions(-)

diff --git a/winsup/cygwin/release/3.0 b/winsup/cygwin/release/3.0
index da0fe0961..da357558d 100644
--- a/winsup/cygwin/release/3.0
+++ b/winsup/cygwin/release/3.0
@@ -31,6 +31,12 @@ What's new:
 - New APIs: signalfd, timerfd_create, timerfd_gettime, timerfd_settime,
   timer_getoverrun.
 
+- fork(2) now is able to recover from when an in-use executable/dll is
+  removed or replaced during process runtime.  This feature is disabled by
+  default and limited to exes/dlls on the same NTFS partition as the Cygwin
+  installation.  For more information and how to enable, please refer to
+  https://www.cygwin.com/cygwin-ug-net/highlights.html#ov-hi-process
+
 
 What changed:
 -------------
diff --git a/winsup/doc/highlights.xml b/winsup/doc/highlights.xml
index 25b227382..67e326cb4 100644
--- a/winsup/doc/highlights.xml
+++ b/winsup/doc/highlights.xml
@@ -202,21 +202,27 @@ While Windows does not allow to remove binaries in use from the file
 system, they still can be renamed or moved into the recycle bin, as
 outlined for unlink(2) in <xref linkend="ov-new1.7-file"></xref>.
 To allow an existing process to fork, the original binary files need to be
-available via their original file names, but they may reside in
-different directories when using the <ulink
+available via their original file names, but they may reside in a
+different directory when using the <ulink
 url="https://social.msdn.microsoft.com/search/en-US?query=dotlocal%20dll%20redirection"
 >DotLocal (.local) Dll Redirection</ulink> feature.
 Since NTFS does support hardlinks, when the fork fails we try again, but
 create a private directory containing hardlinks to the original files as
-well as the .local file now.  The private directory for the hardlinks is
-/var/run/cygfork/, which you have to create manually for now if you need to
-protect fork against exe- and dll- updates on your Cygwin instance.  As
-hardlinks cannot be used across multiple NTFS file systems, please make sure
-your exe- and dll- replacing operations operate on the same single NTFS file
-system as your Cygwin instance and the /var/run/cygfork/ directory.</para>
-
-<para>We create one directory per user, application and application age,
-and remove it when no more processes use that directory.  To indicate
+well as the <literal>.local</literal> file now.  The base directory for the
+private hardlink directory is <literal>/var/run/cygfork/</literal>, which
+you have to create manually for now if you need to protect fork against
+updates to executables and dlls on your Cygwin instance.  As hardlinks
+cannot be used across multiple NTFS file systems, please make sure your
+executable and dll replacing operations operate on the same single NTFS file
+system as your Cygwin instance and the <literal>/var/run/cygfork/</literal>
+directory.  Note that this private hardlink directory also does help for
+when a wrong dll is found in the parent process' current working directory.
+To enable creating the hardlinks, you need to stop all currently running
+Cygwin processes after creating this directory, once per Cygwin installation:
+<literallayout>$ mkdir --mode=a=rwxt /var/run/cygfork</literallayout></para>
+
+<para>We create one hardlink directory per user, application and application
+age, and remove it when no more processes use that directory.  To indicate
 whether a directory still is in use, we define a mutex name similar to
 the directory name.  As mutexes are destroyed when no process holds a
 handle open any more, we can clean up even after power loss or similar:
diff --git a/winsup/doc/new-features.xml b/winsup/doc/new-features.xml
index 6801e3eeb..8fc0ac6fe 100644
--- a/winsup/doc/new-features.xml
+++ b/winsup/doc/new-features.xml
@@ -107,6 +107,13 @@ Native Windows processes not started by Cygwin processes are mapped
 into the range beyond 65535.
 </para></listitem>
 
+<listitem><para>
+fork(2) now is able to recover from when an in-use executable/dll is
+removed or replaced during process runtime.  This feature is disabled by
+default and limited to exes/dlls on the same NTFS partition as the Cygwin
+installation.  For more information and how to enable, please refer to
+<xref linkend="ov-hi-process"></xref>.
+</para></listitem>
 </itemizedlist>
 
 </sect2>
-- 
2.17.0


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

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7

[Corinna Vinschen]

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

On Feb 11 12:50, Michael Haubenwallner wrote:
> 
> 
> On 2/8/19 6:00 PM, Corinna Vinschen wrote:
> > On Feb  8 17:58, Corinna Vinschen wrote:
> >> On Feb  8 17:35, Michael Haubenwallner wrote:
> >>>
> >>> On 2/8/19 2:28 PM, Corinna Vinschen wrote:
> >>>>
> >>>> I pushed your forkable branch to master, btw.  Would you mind to do the
> >>>> honors in the ;rease notes at cygwin/release/3.0 and doc/new-features.xml?
> >>>
> >>> Do you mean like this?
> 
> >>
> >> It's not bad but for release notes it's rather long.  Any chance to get
> >> a more compact text?  Also, please add a "Cygwin: " prefix to the log
> >> message summary.  I'd like to distinguish CYgwin-only changes from
> >> newlib changes.
> > 
> > OTOH, if you want to extend the documentation, feel free...
> 
> Another try, with polish to already available doc around the forkables.

Looks good, pushed.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]