Mail Archives: cygwin/2015/12/06/15:23:42
| 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: | <cygwin.cygwin.com>
|
| List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com>
|
| List-Archive: | <http://sourceware.org/ml/cygwin/>
|
| List-Post: | <mailto:cygwin AT cygwin DOT com>
|
| List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
|
| 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: | <CABPLASTO1iDvebuVz4PAxbfMv7r3SFMsUEKUyavn2tW7eiFhEA@mail.gmail.com>
|
| References: | <announce DOT 20151206185744 DOT GA21712 AT calimero DOT vinschen DOT de> <CABPLASTO1iDvebuVz4PAxbfMv7r3SFMsUEKUyavn2tW7eiFhEA AT mail DOT gmail DOT com>
|
| Date: | Sun, 6 Dec 2015 21:23:20 +0100
|
| Message-ID: | <CABPLASQAk=2j2QYFm4125=Jem6NR+EWTXeeR8uT17y5ZeacrEg@mail.gmail.com>
|
| Subject: | Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.8
|
| From: | Kacper Michajlow <kasper93 AT gmail DOT com>
|
| To: | cygwin AT cygwin DOT com
|
| X-IsSubscribed: | yes
|
I forgot to say. I'm running Windows 10 1511 x64.
2015-12-06 21:21 GMT+01:00 Kacper Michajlow <kasper93 AT gmail DOT com>:
> 2015-12-06 19:57 GMT+01:00 Corinna Vinschen <corinna-cygwin AT cygwin DOT 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
- Raw text -