[ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.4

[ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.4

[Corinna Vinschen]

Hi folks,


I uploaded a new Cygwin test release 3.0.0-0.4

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.3:

- Cygwin PIDs have been decoupled from Windows PID.  Cygwin PIDs are
  now incrementally dealt in the range from 2 up to 65535, POSIX-like.


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.


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: TEST: Cygwin 3.0.0-0.4

[L A Walsh]

On 2/1/2019 11:34 AM, Corinna Vinschen wrote:
>
> - Cygwin PIDs have been decoupled from Windows PID.  Cygwin PIDs are
>   now incrementally dealt in the range from 2 up to 65535, POSIX-like.
>   
----
Posix like?  Posix starts from '1' (usually for init), but
never heard it limited to 65535 ---

Linux allows 32bits (I set it to 99,999) to keep it to 5 digits
and uses /proc/sys/kernel/pid_max to adjust it.

Some systems wrapped too soon and it as confusing so they allowed
for more pids.




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

[Andrey Repin]

Greetings, Corinna Vinschen!

> Changes from 3.0.0-0.3:

> - Cygwin PIDs have been decoupled from Windows PID.  Cygwin PIDs are
>   now incrementally dealt in the range from 2 up to 65535, POSIX-like.

I don't quite get it.
What's the rationale? Why not just use system PID's?


-- 
With best regards,
Andrey Repin
Wednesday, February 6, 2019 3:36:07

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: TEST: Cygwin 3.0.0-0.4

[Corinna Vinschen]

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

On Feb  5 16:31, L A Walsh wrote:
> On 2/1/2019 11:34 AM, Corinna Vinschen wrote:
> >
> > - Cygwin PIDs have been decoupled from Windows PID.  Cygwin PIDs are
> >   now incrementally dealt in the range from 2 up to 65535, POSIX-like.
> >   
> ----
> Posix like?  Posix starts from '1' (usually for init), but
> never heard it limited to 65535 ---

It's just the current limit.  Linux defaults to 32767, BSD to 99999.
PID 1 is the init process and the PID orphaned processes get their
parent PID set to 1.  You don't want a real process in Cygwin get
this PID so it's skipped.

> Linux allows 32bits (I set it to 99,999) to keep it to 5 digits
> and uses /proc/sys/kernel/pid_max to adjust it.

Yes, but this is too much hassle for a start.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

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

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.4

[Corinna Vinschen]

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

On Feb  6 03:36, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> > Changes from 3.0.0-0.3:
> 
> > - Cygwin PIDs have been decoupled from Windows PID.  Cygwin PIDs are
> >   now incrementally dealt in the range from 2 up to 65535, POSIX-like.
> 
> I don't quite get it.
> What's the rationale? Why not just use system PID's?

Using system PIDs requires to keep process handles open for the
only reason so they are not too quickly reused by Windows.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

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

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.4

[Michael Haubenwallner]

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

Hi Andrey,

while not being involved with this change, I may provide some background though:

On 2/6/19 1:36 AM, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
>> Changes from 3.0.0-0.3:
> 
>> - Cygwin PIDs have been decoupled from Windows PID.  Cygwin PIDs are
>>   now incrementally dealt in the range from 2 up to 65535, POSIX-like.
> 
> I don't quite get it.
> What's the rationale? Why not just use system PID's?

To some degree, Cygwin PIDs already have been decoupled from Windows PIDs before.
For example, with POSIX exec() the new process needs to have the same POSIX PID,
but Cygwin does have to create a new Windows process here, so the Windows PID
cannot be used as the POSIX PID within the new process.

Another topic here is PID reusage: A POSIX shell is required to be able to 'wait'
for at least CHILD_MAX unique immediate children processes, as described in
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/wait.html

Cygwin does define CHILD_MAX to be 256, so immediate children should not reuse
a process ID from one of the last 256 wait()ed immediate children processes.

Attached is a bash script to test for when children PIDs get reused.

HTH,
/haubi/

[-- Attachment #2: pid-reuse-count.sh --]
[-- Type: application/x-shellscript, Size: 483 bytes --]

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