2015-12-06 19:57 GMT+01:00 Corinna Vinschen <corinna-cyg...@cygwin.com>: > Hi Cygwin friends and users, > > > I released a new TEST version of Cygwin, 2.4.0-0.8. > > This adds a new feature to cygpath, the -U flag, which allows to > generate /proc/cygdrive paths, which are unambiguous even if the > cygdrive prefix changes. E.g.: > > $ mount -p > Prefix Type Flags > /mnt user binmode > > $ cygpath -D > /mnt/c/Users/corinna/Desktop > > $ ./cygpath -DU > /proc/cygdrive/c/Users/corinna/Desktop > > I'd like to point out the Windows 10 1511 workaround added to 2.4.0-0.7 > again since it's important that it gets tested: > > - Not a bug fix as such, but a workaround for new behaviour in Windows 10 > version 1511 64 bit. This version introduces a problem which existed in > a similar variation (just vice versa) in XP and Server 2003 64 bit as well. > An unexpected stack arrangement when starting a 64 bit Cygwin application > from a 32 bit application (e.g. 32 bit CMD.EXE) broke Cygwin's fork. > Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00003.html > > > ====================================================================== > > Please, please, please test. > > If this code is acceptable, I will create an official 2.4.0 release > next week. > > ====================================================================== > > > This is the "new POSIX ACL handling reloaded" release. > > In local testing I successfully integrated AuthZ into the current Cygwin > code to generate more correct user permissions by being able to generate > effective permissions for arbitrary users. > > This success convinced me that it might be possible to pick up the POSIX > permission rewrite originally targeted for the 2.0.0 release and try to > update it using AuthZ and generally revamp it to reflect effective > permissions better. > > My local testing looks good, but this is a major change, so this code > really needs a lot more testing in various scenarios. Especially > some Windows ACLs created in corporate environments are often a hard > nut to crack, and the example from > > https://cygwin.com/ml/cygwin/2015-04/msg00513.html > > which was the ultimate downfall of the original implementation is > the stuff which needs some good testing. > > There's, as usual, a downside: AuthZ leans a bit to the slow side. > Cygwin caches information already gathered once on a per-process basis, > but in locally crafted worst case scenarios (`ls' on lots of file owned > by lots of different users and groups) the slowdown may be up to 25%. > But that's really just a worst case, in the usual scenarios the slowdown > should be mostly unnoticable. > > To alleviate the problem, the AuthZ code is fortunately only called for > non-Cygwin ACLs and Cygwin ACLs created before this release. Within a > pure Cygwin environment (e.g., some build directory only used with > Cygwin tools) AuthZ should be practically unused. > > Apart from the aforementioned code changes to "just do it right", there > are two additional changes I implemented for this new POSIX ACL revamp > release: > > - I reverted the questionable change I added to 2.0.0-0.7 in terms of > chmod group permission handling. The original description of this > change was: > > If you have a non-trivial ACL with secondary accounts and thus a > mask value, chmod is supposed to change only the mask, not the > permissions of the primary group. However, if the primary group has > few permissions to begin with, the result is really surprising. ls > -l would, e.g., show read/write perms for the group, but the group > might still have only read perms. > > Personally I find this chmod behaviour really, really bad, so I took > the liberty to change it in a way which gives a much less surprising > result: If you call chmod on a non-trivial ACL, the group > permissions will be used for the primary group and the mask. > > - setfacl(1) now accepts the combination of the -b and -k options, just as > on Linux. > > As for the description what this implementation strives for, please see > http://linux.die.net/man/5/acl > > ============================================================================ > > What's new: > ----------- > > - New, unified implementation of POSIX permission and ACL handling. The > new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and > they allow to inherit the S_ISGID bit. ACL inheritance now really > works as desired, in a limited, but theoretically equivalent fashion > even for non-Cygwin processes. > > To accommodate standard Windows ACLs, the POSIX permissions of the > owner and all other users in the ACL are computed using the Windows > AuthZ API. This may slow down the computation of POSIX permissions > noticably in some circumstances, but is generally more correct. The > new code also ignores SYSTEM and Administrators group permissions when > computing the MASK/CLASS_OBJ permission mask on old ACLs, and it > doesn't deny access to SYSTEM and Administrators group based on the > value of MASK/CLASS_OBJ when creating the new ACLs. > > The new code now handles the S_ISGID bit on directories as on Linux: > Setting S_ISGID on a directory causes new files and subdirs created > within to inherit its group, rather than the primary group of the user > who created the file. This only works for files and directories > created by Cygwin processes. > > - New API: rpmatch. > > > What changed: > ------------- > > - setfacl(1) now allows to use the -b and -k option combined to allow reducing > an ACL to only reflect standard POSIX permissions. > > - Fix (numeric and monetary) decimal point and thousands separator in > fa_IR and ps_AF locales to be aligned with Linux. > > > Bug Fixes > --------- > > - Not a bug fix as such, but a workaround for new behaviour in Windows 10 > version 1511 64 bit. This version introduces a problem which existed in > a similar variation (just vice versa) in XP and Server 2003 64 bit as well. > An unexpected stack arrangement when starting a 64 bit Cygwin application > from a 32 bit application (e.g. 32 bit CMD.EXE) broke Cygwin's fork. > Addresses: https://cygwin.com/ml/cygwin/2015-12/msg00003.html > > - Replaced old, buggy strtold implementation with well-tested gdtoa version > from David M. Gay. > Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00205.html > > - Fix handling of relative paths in native symlinks if the target is in a > drive's root dir or one level below. > Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00277.html > > - Fix a SEGV when calling `kill -l 0'. > Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00430.html > > - Fix a race condition in signal handling. > Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00387.html > > ============================================================================ > > > 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 >
Hi, Since 2015-12-03 snapshot I got only black screen when running this batch script @echo off C: chdir C:\cygwin\bin zsh -l -i Basically it deadlocks while processing .zshrc. I was debugging this and it locks when loading "oh my zsh". Long story short is seems to hang here https://github.com/robbyrussell/oh-my-zsh/blob/master/lib/git.zsh#L177 at least for the first time, because if I remove this line it hangs somewhere else. It basically hangs if in git_compare_version() is any kind of external command which cause fork. It works fine when running from mintty. -- 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
