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=ls PbcnOwFXBDkZyrwoCCV1G6Cp84RIE7TEB69/O9PsQdhxjpgL/UulTc6ZHuQ6sX9M FU0S4kfWg/n8PZyLM9G0ZEAH+nAVkttZZ8cLjZzp6u62P7cLPjZoFPQat+Fn3XtH 1kRu+PClXLobbiEQKSfI6CHwY83TYBJbD8dzM69h4= 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=l3DQnUJ6 1sJx6R14V/EIiG5LBSs=; b=d4HlMN4fGVkLS/TFciAX0XZx7DiqxR4Aq689iP3q SnsV3IG3MK8h/NXXwdzskQqK8D2AegPS/HIUuIKD5WgqQJY6q8w/d5jOcD8AjoCw 5NC+mhXHJ2wnHNHQOfkBUVgAQzywUY2q9iTBUE/56ZImAMYq25yNsO2/mfDVj9+/ PGc= 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.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lb0-f182.google.com MIME-Version: 1.0 X-Received: by 10.112.54.165 with SMTP id k5mr17935650lbp.57.1429010688694; Tue, 14 Apr 2015 04:24:48 -0700 (PDT) In-Reply-To: <20150414092313.GE7343@calimero.vinschen.de> References: <20150414080044 DOT GB7343 AT calimero DOT vinschen DOT de> <20150414092313 DOT GE7343 AT calimero DOT vinschen DOT de> Date: Tue, 14 Apr 2015 07:24:48 -0400 Message-ID: Subject: Re: Making Cygwin More Tolerant of Orphaned SIDs? From: Bryan Berns To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes On Tue, Apr 14, 2015 at 4:00 AM, Corinna Vinschen > > The problem is that Cygwin, or any other tool trying to resolve SIDs > doesn't know a SID won't resolve before it tried. And then it's an > OS function which takes its time. It's like checking for network > machines providing shares. Sometimes this test takes ages, but in > this case, fortunately, you see that it takes ages in Explorer as > well. > > As for ACLs, you can alleviate the problem somewhat by running cygserver > on the machine, which allows to cache SIDs for all processes. So only > the first process trying the SID will take time, followup processes will > get the cached results from cygserver. > > Other than that, except for ignoring ACLs entirely (noacl) I have > no idea how to solve this problem differently. Yes, I understand there's nothing Cygwin can do beforehand -- that means sense. I guess what I'm saying is that Cygwin doesn't appear to be caching SIDs in certain scenarios. For example, I create a whole bunch of files (like 5000), I use icacls to append a new ACE. Then I do a 'time ls -l /cygdrive/c/somedir/*'. Takes four seconds. In the same Cygwin session, I remove the local group (net localgroup testgroup /delete). I do the same 'time ls -l /cygdrive/c/somedir/*'. Takes 20 seconds. Subsequent runs in the also take 20 seconds. Since I'm able to continue to see the slowdown in the same session, cygserver wouldn't help right? Is the above expected? If not and it's something you're willing to take a look at, I can certainly come up with a little script to demonstrate the issue. -- 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