X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; q=dns; s=default; b=E2 VupTMId56bESIGAQi4AMWsJddGbGKjnLOXQs9l3ibypaA9S0bJaUj2W+X3XJ6H+0 FLA6S2TSvV7xofB3L+O6xi+tr6/i5VW6pS9Y5hrv8e2rEl7MxEMP+pInN+0Lc8Pe aw1RixvuLJj6YBroLZAH2mJhzjL3WMTvTf/eRnwyM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; s=default; bh=6OWoaTw9 GP5Q5uYA8j3pOS6KmfU=; b=x1Lj1vHMxUwDdOJPaT9FvWoCQOuFJ6V4ZUIy1+lZ Vuuy6qYJRgaP2hofsxbsjicdZjcV8Jl7/RHvs7YV31C29G0uPpr4LUDud8hFtWLT nvNDJBElU4LMhJWxQO1GtntXKM35yG8o9x1JzKC4F2BDKv/uu6EXqfY9gXxK7SmU 12U= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_50,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-wm0-f42.google.com MIME-Version: 1.0 X-Received: by 10.194.114.164 with SMTP id jh4mr159599wjb.153.1449433400268; Sun, 06 Dec 2015 12:23:20 -0800 (PST) In-Reply-To: References: Date: Sun, 6 Dec 2015 21:23:20 +0100 Message-ID: Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.8 From: Kacper Michajlow To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes I forgot to say. I'm running Windows 10 1511 x64. 2015-12-06 21:21 GMT+01:00 Kacper Michajlow : > 2015-12-06 19:57 GMT+01:00 Corinna Vinschen : >> 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