2019-02-18 05:51:21 +08:00
|
|
|
What's new:
|
|
|
|
-----------
|
|
|
|
|
2019-02-20 04:34:18 +08:00
|
|
|
- New API: secure_getenv.
|
|
|
|
|
2019-02-18 05:51:21 +08:00
|
|
|
|
|
|
|
What changed:
|
|
|
|
-------------
|
|
|
|
|
|
|
|
|
|
|
|
Bug Fixes
|
|
|
|
---------
|
|
|
|
|
|
|
|
- Relax fork child permissions to avoid a potential fork failure.
|
|
|
|
Addresses: https://cygwin.com/ml/cygwin/2019-02/msg00234.html
|
2019-02-18 05:59:36 +08:00
|
|
|
|
|
|
|
- Fix Command-line argument handling of kill(1) in terms of negative PID.
|
|
|
|
Addresses: report on IRC
|
Cygwin: mount: define binary mount as default
Commit c1023ee353705671aa9a8e4e1179022277add2aa changed the way
path_conv::binmode() works. Rather than returning three states,
O_BINARY, O_TEXT, 0, it only returned 2 states, O_BINARY, O_TEXT. Since
mounts are only binary if they are explicitely mounted binary by setting
the MOUNT_BINARY flag, textmode is default.
This introduced a new bug. When inheriting stdio HANDLEs from native
Windows processes, the fhandler and its path_conv are created from a
device struct only. None of the path or mount flags get set this way.
So the mount flags are 0 and path_conv::binmode() returned 0.
After the path_conv::binmode() change it returned O_TEXT since, as
explained above, the default mount mode is textmode.
Rather than just enforcing binary mode for path_conv's created from
device structs, this patch changes the default mount mode to binary:
Replace MOUNT_BINARY flag with MOUNT_TEXT flag with opposite meaning.
Drop all explicit setting of MOUNT_BINARY. Drop local set_flags
function, it doesn't add any value.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
2019-02-18 17:12:07 +08:00
|
|
|
|
|
|
|
- Fix an accidentally introduced O_TEXT handling of pipes inherited
|
|
|
|
from native Windows processes.
|
|
|
|
Addresses: https://cygwin.com/ml/cygwin/2019-02/msg00246.html
|
2019-02-19 04:00:59 +08:00
|
|
|
|
|
|
|
- Re-enable creating user token from scratch in seteuid to allow
|
|
|
|
user context switch on old systems not supporting MsV1_0S4ULogon.
|
|
|
|
Addresses: https://cygwin.com/ml/cygwin/2019-02/msg00277.html
|