From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57587 invoked by alias); 14 May 2016 12:04:09 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 57575 invoked by uid 89); 14 May 2016 12:04:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=versus, H*r:sk:22.2016, discussions, 50am X-HELO: mail-wm0-f42.google.com Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com) (74.125.82.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 14 May 2016 12:03:58 +0000 Received: by mail-wm0-f42.google.com with SMTP id e201so50427478wme.0 for ; Sat, 14 May 2016 05:03:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=38TgQgRYxwkYGr/AR3Rc8A9lbIx8pREpECoEMTgx4SY=; b=Bu4gbkvUSNGzijawigOtoghPCiq9RfT6xEtk8eGbzOZgzyQsteWNW32fuUgA4eUuwK Qx84BkqMAYZeHl3PxG8L8dnd8Z57Ys9UxTEEO7WsioWZ9Nc4dk/Rss2JXs9GM+H18iA4 dUBZP1wYIeyJj91koMWYSihMave+BjEg9Wyfn/rx6HRdmPH37nvGZyCdm9gJg3LrtPDl txuKxO5txeyPOziqC9MiIqLyvfc5QPRrrrOyzw5aaTR4QAS4FuUN4xIOZnPGV18vqJoT On2tdUN7nxJKkMnKn/7UeeOY7t8dMHVqqM849VOgXN34z7vliLm7op2z62VbDVNYhfd9 ABrg== X-Gm-Message-State: AOPr4FUsnk4rPM916yyW7cRQrsZFwCYuVlh6LDS53CvyHKDkWovAh+qtN42KlbcUyKtQ+Q== X-Received: by 10.194.248.135 with SMTP id ym7mr20552772wjc.174.1463227435679; Sat, 14 May 2016 05:03:55 -0700 (PDT) Received: from dinwoodie.org ([2001:ba8:0:1c0::9:1]) by smtp.gmail.com with ESMTPSA id f11sm8047903wmf.22.2016.05.14.05.03.54 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sat, 14 May 2016 05:03:54 -0700 (PDT) Date: Sat, 14 May 2016 12:04:00 -0000 From: Adam Dinwoodie To: cygwin@cygwin.com Subject: Re: Possible issue with newest version of git (v 2.8) under Cygwin Message-ID: <20160514120353.GH2345@dinwoodie.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg00170.txt.bz2 On Tue, May 10, 2016 at 09:59:50AM -0400, andrew stern wrote: > >I'm not sure I understand what you're seeing: if your repository is > >already set up with core.filemode set to false, Git won't check the > >executable flag on the files. What leads you to think the speed > >slow-down is related to checking whether the file is executable? > > >If setting cygexec makes a noticable speed difference even with > >core.filemode false, I can only conclude the problem is somewhere > >below Git and related to how the Cygwin DLL provides file access. > > >FWIW, having just checked the Cygwin user guide's fstab > >instructions[0], the noacl setting should be ignored on NFS > >filesystems; if you're seeing that make a difference, that looks like > >a bug. > > I tried a clone and pull both with the noacl and without the noacl. In > my experiment without the noacl it was much faster when doing pulls > after someone else checked in changes. I located on the web a > reference to noacl being slow when doing a stat under cygwin and > figured if I prevent reading each file it might be faster so I went to > my noacl directory and did a pull of their changes after adding the > cygexec flag after the noacl flag. Instead of being tens of minutes > it was just a bit over a minute and a half. To be absolutely clear: if you mount an NFS share with noacl set, you get a noticable speed increase versus not setting noacl? > Although the repository > is on a NFS drive the local file system is NTFS and I see it spending > lots of time doing the update on the merge even though it is just a > couple of files that have changed. I'm still trying to figure out > what exactly is going on and how best to deal with the permissioning > issue that we are now experiencing. After discussions we would rather > have it slow then have bad permission problems but I'd rather not have > either issue. Am I correct in understanding you have multiple users trying to access the same shared Git working repository? I'm aware it's a workaround rather than an actual solution, but I'd expect you'd have better luck with each having a separate working copy on your local machine rather than sharing a common working copy. > If I leave off the noacl and do a clone followed by a push and pull we > end up with the following error in the Windows security tab: > The permissions on file.cpp are incorrectly ordered, which may cause > some entries to be ineffective. Yes, I've seen that before; it's a problem with the underlying cygwind1.dll rather than a problem with Git. I believe the consensus from people on this list who know more about Windows permissions than me is that the warning is actually benign and can be ignored. -- 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