This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Possible issue with newest version of git (v 2.8) under Cygwin

>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.  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.

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.

It also leaves the permissions looking like this

Deny        NULL SID                           Special
    not Inherited
Allow        User                                  Special
         not Inherited
Deny        dev group                           Traverse folder...
     not Inherited
Deny        Authenticated Users           Traverse folder...
not Inherited
Deny        SYSTEM                           Traverse folder...
  not Inherited
Deny        Administrators for machine  Traverse folder...
not Inherited
Deny        Users for machine               Traverse folder...
 not Inherited
Allow        dev group                           Read & execute
   not Inherited
Allow        Authenticated Users           Read, Write & execute  not Inherited
Allow        SYSTEM                           Read, Write & execute
not Inherited
Allow        Administrators for machine  Read, Write & execute  not Inherited
Allow        Users for machine              Read & execute
not Inherited
Allow        Everyone                           Read
         not Inherited

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]