www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2015/12/06/15:22:02

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=bF
WCH84lU14kF7F6ylk4igGj6wMVklEhpCnFu1QGtjBtC/9ngl1sX1RMk4gzgXzzFQ
DfAi9eWw01tdSR21f5EdvjmZdQn+0CA8aOfl1muBhtcfwlp9AimvpAYbIKiNyLSl
kPPJP5P9yg4QJhdrgip5S3qZ4VOUEj6wKjj6fDxBU=
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=OZWPaI5o
15RCERe04MBqaAH1wSA=; b=LH0eSjSQETB7tiSAikdqDLl1/PXRqHDXC1IebMBk
X8nTNNoXzFs3/vXQvrEeRZEsMB9FgN74Vj1e1dkyO9QCkfKr2VWJM/+JEvit3pIi
ZzYji9q6cFW+YEUq13gH0o+LND1VEZui8RHsOwFkjb4CSzkKAJIBh/ChNNEHx+bE
UTk=
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.3 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-f52.google.com
MIME-Version: 1.0
X-Received: by 10.194.79.72 with SMTP id h8mr32149958wjx.136.1449433300209; Sun, 06 Dec 2015 12:21:40 -0800 (PST)
In-Reply-To: <announce.20151206185744.GA21712@calimero.vinschen.de>
References: <announce DOT 20151206185744 DOT GA21712 AT calimero DOT vinschen DOT de>
Date: Sun, 6 Dec 2015 21:21:40 +0100
Message-ID: <CABPLASTO1iDvebuVz4PAxbfMv7r3SFMsUEKUyavn2tW7eiFhEA@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

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019