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

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

[andrew stern]

>I suspect this isn't a problem with the Git upgrade but with recent
>changes that have been being made to how the core Cygwin dll handles
>permissions.

>That being said, can you try running `git config core.filemode false` in
>the repository, re-enabling noacl, and see if that has things running at
>something more like normal speed?  That disables Git's checks on file
>permissions, so it should isolate whether the slow-down is specifically
>Git checking permissions or if merely accessing files is the problem.

>(With core.filemode disabled, you'll need to use `git update-index` to
>add/remove the executable flag on files in the Git repository; see `git
>help update-index` for details on how that works.  To undo the config
>change, use `git config core.filemode true`.)

This repository is created with the filemode=false after I finish
cloning from the repository using cygwin.
I've decided to try cygexec on the fstab to see if it helps and it
does seem much faster.
I don't know if this is the correct way to speed it up again but the
speed slow down does seem related to reading each file and determining
if it is executable.
The new line is:
none /cygdrive cygdrive binary,posix=0,user,noacl,cygexec 0 0

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

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

[Adam Dinwoodie]

On Tue, May 10, 2016 at 09:15:48AM -0400, andrew stern wrote:
> >I suspect this isn't a problem with the Git upgrade but with recent
> >changes that have been being made to how the core Cygwin dll handles
> >permissions.
> 
> >That being said, can you try running `git config core.filemode false` in
> >the repository, re-enabling noacl, and see if that has things running at
> >something more like normal speed?  That disables Git's checks on file
> >permissions, so it should isolate whether the slow-down is specifically
> >Git checking permissions or if merely accessing files is the problem.
> 
> >(With core.filemode disabled, you'll need to use `git update-index` to
> >add/remove the executable flag on files in the Git repository; see `git
> >help update-index` for details on how that works.  To undo the config
> >change, use `git config core.filemode true`.)
> 
> This repository is created with the filemode=false after I finish
> cloning from the repository using cygwin.
> I've decided to try cygexec on the fstab to see if it helps and it
> does seem much faster.
> I don't know if this is the correct way to speed it up again but the
> speed slow down does seem related to reading each file and determining
> if it is executable.
> The new line is:
> none /cygdrive cygdrive binary,posix=0,user,noacl,cygexec 0 0

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.

[0]: https://cygwin.com/cygwin-ug-net/using.html#mount-table

Adam

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

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

[andrew stern]

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

>As I read the Cygwin documentation, the problem is that windows permissions and POSIX permissions don't line up very well. In order to faithfully reproduce POSIX permissions, Cygwin uses legal but non-standard ordering of ACEs.
> Windows' security tab thinks this is a problem, but it really isn't. To quote from the documentation here:
>https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files:

>    Unfortunately the security tab in the file properties dialog of the
>    Windows Explorer insists to rearrange the order of the ACEs to
>    canonical order before you can read them. Thank God, the sort order
>    remains unchanged if one presses the Cancel button. But don't even
>    *think* of pressing OK...

> So it would seem the problem as such lies with Windows' security tab.

I would agree if it wasn't for the fact that even without looking at
the permissions tab we ended up with the inability for anyone else in
the group to write or update the head for the repository.  This is a
much bigger issue then just a display issue in Windows.  It is causing
read write permission issues where members can't push changes from
their local trees after another team member pushes their changes.  It
seems to mess it up in such a way that a system admin must reset
permissions after each push so that another team member can push their
changes.  This just started happening after updating cygwin in the
last few weeks and is related to changes to the ACL that were done in
the last couple of months.

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

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

[andrew stern]

>To be absolutely clear: if you mount an NFS share with noacl set, you get a noticable speed increase versus not setting noacl?
Let me clear this up a bit.  The group is working on local
repositories that happen to exist on local NTFS drives under Windows.
These drives are the same local drives that we make changes to before
pushing up the changes.  The local drives when mounted using the
default setting for cygwin is much slower then when we add noacl to
the fstab files mount line.  The NFS drives isn't accessed directly
except though git commands because we store our common repository on a
shared drive instead of running a git server like github or gitblit.

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

We do have local copies but we have to push our changes somewhere
after we change our local tree.  In this case it is a shared NFS
drive.

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

The warning isn't benign in this case as it messes up the permissions
so that all the other team members no longer have write permissions so
that they can't check in their changes.   Before the recent ACL
changes to cygwin we worked without any issues and have been using git
and cygwin for years before these changes.

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

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

[Norton Allen]

On 5/14/2016 8:03 AM, Adam Dinwoodie wrote:
>> 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.

As I read the Cygwin documentation, the problem is that windows 
permissions and POSIX permissions don't line up very well. In order to 
faithfully reproduce POSIX permissions, Cygwin uses legal but 
non-standard ordering of ACEs. Windows' security tab thinks this is a 
problem, but it really isn't. To quote from the documentation here: 
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files:

    Unfortunately the security tab in the file properties dialog of the
    Windows Explorer insists to rearrange the order of the ACEs to
    canonical order before you can read them. Thank God, the sort order
    remains unchanged if one presses the Cancel button. But don't even
    *think* of pressing OK...

So it would seem the problem as such lies with Windows' security tab.

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

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

[Adam Dinwoodie]

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

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

[andrew stern]

>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:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

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

[Adam Dinwoodie]

On Mon, May 09, 2016 at 03:59:39PM -0400, andrew stern wrote:
> If I change my fstab back so that it does not include the noacl option
> on the line the merge is much faster:
> 
> 15:51:22.288607 git.c:350               trace: built-in: git 'merge'
> 'FETCH_HEAD' Updating 154cf50..a0f35eb
> Fast-forward
> 15:55:18.347594 run-command.c:336       trace: run_command: 'gc' '--auto'
> 
> So it is clear that my fix for the Windows permissions is causing the
> merge to take a very long time.
> 
> 
> On 9 May 2016 at 14:34, andrew stern <> wrote:
> > Recently I upgraded to version 2.8.0 of git on cygwin.  I’m running
> > under Windows 2008 R2.  Before this upgrade we were able to share a
> > NFS drive as a main repository.  After the upgrade the permissions
> > were changed so that only a single person had write access to the
> > repository on a shared NFS drive.  When the push is done to the NFS
> > drive these permissions cause deny write access to the other users of
> > the repository so we couldn’t update the sha1 of the head reference.
> > An example of the incorrect permissions are:
> >
> >
> > Allow     User                         Special            not
> > inherited      This folder only
> > Allow     dev                          Special            not
> > inherited     This folder only
> > Allow     Everyone                     Read & execute     not
> > inherited      This folder, subfolders and
> > Allow     Administators for machine    Special            not
> > inherited      This folder only
> > Allow     SYSTEM                       Special            not
> > inherited      This folder only
> > Allow     Users for machine            Special            not
> > inherited      This folder only
> > Allow     CREATOR OWNER                Special            not
> > inherited     Subfolders and files only
> > Allow     CREATOR GROUP                Special            not
> > inherited     Subfolders and files only
> >
> > But the Windows permissions should have been inherited only.  Also not
> > the group dev is not in the list.  The permissions after a push showed
> > dev on the shared NFS drive along with errors that the permissions
> > were out of order.
> >
> > Allow     Administators           Full Control       D:\  This folder,
> > subfolders and
> > Allow     SYSTEM                  Full Control       D:\  This folder,
> > subfolders and
> > Allow     User                    Special            D:\  This folder only
> > Allow     CREATOR OWNER           Special            D:\  Subfolders
> > and files only
> > Allow     User on Machine         Read & execute     D:\  This folder,
> > subfolders and
> > Allow     User on Machine         Special            D:\  This folder,
> > subfolders
> >
> >
> > After searching through new groups and the web it was decided to add
> > noacl to the fstab for the cygwin mount:
> >
> > none /cygdrive cygdrive binary,posix=0,user,noacl 0 0
> >
> > Now we are finding that the git merge onto our local drive after a
> > fetch from the NFS shared repository is taking a very long time.
> > (shown with >> in front on below line)
> >
> > $ git pull origin MCSTRATEGY_4_4
> > 13:01:16.587064 git.c:351               trace: built-in: git 'pull'
> > 'origin' 'MCSTRATEGY_4_4'
> > 13:01:16.752064 run-command.c:336       trace: run_command: 'fetch'
> > '--update-head-ok' 'origin' 'MCSTRATEGY_4_4'
> > 13:01:16.790064 exec_cmd.c:120          trace: exec: 'git' 'fetch'
> > '--update-head-ok' 'origin' 'MCSTRATEGY_4_4'
> > 13:01:16.821064 git.c:351               trace: built-in: git 'fetch'
> > '--update-head-ok' 'origin' 'MCSTRATEGY_4_4'
> > 13:01:17.069064 run-command.c:336       trace: run_command:
> > 'git-upload-pack
> > '\''/cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.'\'''
> > 13:01:17.136064 run-command.c:195       trace: exec: '/bin/sh' '-c'
> > 'git-upload-pack
> > '\''/cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.'\'''
> > 'git-upload-pack
> > '\''/cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.'\'''
> > 13:01:18.084064 run-command.c:336       trace: run_command: 'rev-list'
> > '--objects' '--stdin' '--not' '--all' '--quiet'
> > 13:01:18.229064 run-command.c:336       trace: run_command: 'rev-list'
> > '--objects' '--stdin' '--not' '--all'
> > 13:01:18.284064 exec_cmd.c:120          trace: exec: 'git' 'rev-list'
> > '--objects' '--stdin' '--not' '--all'
> > 13:01:18.314064 git.c:351               trace: built-in: git
> > 'rev-list' '--objects' '--stdin' '--not' '--all'
> > From /cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.
> >  * branch            MCSTRATEGY_4_4 -> FETCH_HEAD
> > 13:01:18.367064 run-command.c:952       run_processes_parallel:
> > preparing to run up to 1 tasks
> > 13:01:18.373064 run-command.c:984       run_processes_parallel: done
> > 13:01:18.375064 run-command.c:336       trace: run_command: 'gc' '--auto'
> > 13:01:18.410064 exec_cmd.c:120          trace: exec: 'git' 'gc' '--auto'
> > 13:01:18.440064 git.c:351               trace: built-in: git 'gc' '--auto'
> > 13:01:18.454064 run-command.c:336       trace: run_command: 'merge' 'FETCH_HEAD'
> > 13:01:18.486064 exec_cmd.c:120          trace: exec: 'git' 'merge' 'FETCH_HEAD'
> >>> 13:01:18.517064 git.c:351               trace: built-in: git 'merge' 'FETCH_HEAD'
> > Updating 9c40e07..a0f35eb
> > Fast-forward
> > 13:18:39.432839 run-command.c:336       trace: run_command: 'gc' '--auto'
> > 13:18:43.559539 exec_cmd.c:120          trace: exec: 'git' 'gc' '--auto'
> > 13:18:43.623539 git.c:351               trace: built-in: git 'gc' '--auto'
> >  file.cpp | 5 +++--
> >
> > First question is could this very large delay on git merge be caused
> > by the noacl?  If noacl is causing this very large delay (which I
> > suspect to be the case since we didn’t have this large delay till the
> > noacl was added) is there another way to fix the permission issue when
> > using an NFS drive as a shared repository?

I suspect this isn't a problem with the Git upgrade but with recent
changes that have been being made to how the core Cygwin dll handles
permissions.

That being said, can you try running `git config core.filemode false` in
the repository, re-enabling noacl, and see if that has things running at
something more like normal speed?  That disables Git's checks on file
permissions, so it should isolate whether the slow-down is specifically
Git checking permissions or if merely accessing files is the problem.

(With core.filemode disabled, you'll need to use `git update-index` to
add/remove the executable flag on files in the Git repository; see `git
help update-index` for details on how that works.  To undo the config
change, use `git config core.filemode true`.)

Adam

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

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

[andrew stern]

If I change my fstab back so that it does not include the noacl option
on the line the merge is much faster:

15:51:22.288607 git.c:350               trace: built-in: git 'merge'
'FETCH_HEAD' Updating 154cf50..a0f35eb
Fast-forward
15:55:18.347594 run-command.c:336       trace: run_command: 'gc' '--auto'

So it is clear that my fix for the Windows permissions is causing the
merge to take a very long time.


On 9 May 2016 at 14:34, andrew stern <astern.fix8.forum@gmail.com> wrote:
> Recently I upgraded to version 2.8.0 of git on cygwin.  I’m running
> under Windows 2008 R2.  Before this upgrade we were able to share a
> NFS drive as a main repository.  After the upgrade the permissions
> were changed so that only a single person had write access to the
> repository on a shared NFS drive.  When the push is done to the NFS
> drive these permissions cause deny write access to the other users of
> the repository so we couldn’t update the sha1 of the head reference.
> An example of the incorrect permissions are:
>
>
> Allow     User                         Special            not
> inherited      This folder only
> Allow     dev                          Special            not
> inherited     This folder only
> Allow     Everyone                     Read & execute     not
> inherited      This folder, subfolders and
> Allow     Administators for machine    Special            not
> inherited      This folder only
> Allow     SYSTEM                       Special            not
> inherited      This folder only
> Allow     Users for machine            Special            not
> inherited      This folder only
> Allow     CREATOR OWNER                Special            not
> inherited     Subfolders and files only
> Allow     CREATOR GROUP                Special            not
> inherited     Subfolders and files only
>
> But the Windows permissions should have been inherited only.  Also not
> the group dev is not in the list.  The permissions after a push showed
> dev on the shared NFS drive along with errors that the permissions
> were out of order.
>
> Allow     Administators           Full Control       D:\  This folder,
> subfolders and
> Allow     SYSTEM                  Full Control       D:\  This folder,
> subfolders and
> Allow     User                    Special            D:\  This folder only
> Allow     CREATOR OWNER           Special            D:\  Subfolders
> and files only
> Allow     User on Machine         Read & execute     D:\  This folder,
> subfolders and
> Allow     User on Machine         Special            D:\  This folder,
> subfolders
>
>
> After searching through new groups and the web it was decided to add
> noacl to the fstab for the cygwin mount:
>
> none /cygdrive cygdrive binary,posix=0,user,noacl 0 0
>
> Now we are finding that the git merge onto our local drive after a
> fetch from the NFS shared repository is taking a very long time.
> (shown with >> in front on below line)
>
> $ git pull origin MCSTRATEGY_4_4
> 13:01:16.587064 git.c:351               trace: built-in: git 'pull'
> 'origin' 'MCSTRATEGY_4_4'
> 13:01:16.752064 run-command.c:336       trace: run_command: 'fetch'
> '--update-head-ok' 'origin' 'MCSTRATEGY_4_4'
> 13:01:16.790064 exec_cmd.c:120          trace: exec: 'git' 'fetch'
> '--update-head-ok' 'origin' 'MCSTRATEGY_4_4'
> 13:01:16.821064 git.c:351               trace: built-in: git 'fetch'
> '--update-head-ok' 'origin' 'MCSTRATEGY_4_4'
> 13:01:17.069064 run-command.c:336       trace: run_command:
> 'git-upload-pack
> '\''/cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.'\'''
> 13:01:17.136064 run-command.c:195       trace: exec: '/bin/sh' '-c'
> 'git-upload-pack
> '\''/cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.'\'''
> 'git-upload-pack
> '\''/cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.'\'''
> 13:01:18.084064 run-command.c:336       trace: run_command: 'rev-list'
> '--objects' '--stdin' '--not' '--all' '--quiet'
> 13:01:18.229064 run-command.c:336       trace: run_command: 'rev-list'
> '--objects' '--stdin' '--not' '--all'
> 13:01:18.284064 exec_cmd.c:120          trace: exec: 'git' 'rev-list'
> '--objects' '--stdin' '--not' '--all'
> 13:01:18.314064 git.c:351               trace: built-in: git
> 'rev-list' '--objects' '--stdin' '--not' '--all'
> From /cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.
>  * branch            MCSTRATEGY_4_4 -> FETCH_HEAD
> 13:01:18.367064 run-command.c:952       run_processes_parallel:
> preparing to run up to 1 tasks
> 13:01:18.373064 run-command.c:984       run_processes_parallel: done
> 13:01:18.375064 run-command.c:336       trace: run_command: 'gc' '--auto'
> 13:01:18.410064 exec_cmd.c:120          trace: exec: 'git' 'gc' '--auto'
> 13:01:18.440064 git.c:351               trace: built-in: git 'gc' '--auto'
> 13:01:18.454064 run-command.c:336       trace: run_command: 'merge' 'FETCH_HEAD'
> 13:01:18.486064 exec_cmd.c:120          trace: exec: 'git' 'merge' 'FETCH_HEAD'
>>> 13:01:18.517064 git.c:351               trace: built-in: git 'merge' 'FETCH_HEAD'
> Updating 9c40e07..a0f35eb
> Fast-forward
> 13:18:39.432839 run-command.c:336       trace: run_command: 'gc' '--auto'
> 13:18:43.559539 exec_cmd.c:120          trace: exec: 'git' 'gc' '--auto'
> 13:18:43.623539 git.c:351               trace: built-in: git 'gc' '--auto'
>  file.cpp | 5 +++--
>
> First question is could this very large delay on git merge be caused
> by the noacl?  If noacl is causing this very large delay (which I
> suspect to be the case since we didn’t have this large delay till the
> noacl was added) is there another way to fix the permission issue when
> using an NFS drive as a shared repository?

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

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

[andrew stern]

Recently I upgraded to version 2.8.0 of git on cygwin.  I’m running
under Windows 2008 R2.  Before this upgrade we were able to share a
NFS drive as a main repository.  After the upgrade the permissions
were changed so that only a single person had write access to the
repository on a shared NFS drive.  When the push is done to the NFS
drive these permissions cause deny write access to the other users of
the repository so we couldn’t update the sha1 of the head reference.
An example of the incorrect permissions are:


Allow     User                         Special            not
inherited      This folder only
Allow     dev                          Special            not
inherited     This folder only
Allow     Everyone                     Read & execute     not
inherited      This folder, subfolders and
Allow     Administators for machine    Special            not
inherited      This folder only
Allow     SYSTEM                       Special            not
inherited      This folder only
Allow     Users for machine            Special            not
inherited      This folder only
Allow     CREATOR OWNER                Special            not
inherited     Subfolders and files only
Allow     CREATOR GROUP                Special            not
inherited     Subfolders and files only

But the Windows permissions should have been inherited only.  Also not
the group dev is not in the list.  The permissions after a push showed
dev on the shared NFS drive along with errors that the permissions
were out of order.

Allow     Administators           Full Control       D:\  This folder,
subfolders and
Allow     SYSTEM                  Full Control       D:\  This folder,
subfolders and
Allow     User                    Special            D:\  This folder only
Allow     CREATOR OWNER           Special            D:\  Subfolders
and files only
Allow     User on Machine         Read & execute     D:\  This folder,
subfolders and
Allow     User on Machine         Special            D:\  This folder,
subfolders


After searching through new groups and the web it was decided to add
noacl to the fstab for the cygwin mount:

none /cygdrive cygdrive binary,posix=0,user,noacl 0 0

Now we are finding that the git merge onto our local drive after a
fetch from the NFS shared repository is taking a very long time.
(shown with >> in front on below line)

$ git pull origin MCSTRATEGY_4_4
13:01:16.587064 git.c:351               trace: built-in: git 'pull'
'origin' 'MCSTRATEGY_4_4'
13:01:16.752064 run-command.c:336       trace: run_command: 'fetch'
'--update-head-ok' 'origin' 'MCSTRATEGY_4_4'
13:01:16.790064 exec_cmd.c:120          trace: exec: 'git' 'fetch'
'--update-head-ok' 'origin' 'MCSTRATEGY_4_4'
13:01:16.821064 git.c:351               trace: built-in: git 'fetch'
'--update-head-ok' 'origin' 'MCSTRATEGY_4_4'
13:01:17.069064 run-command.c:336       trace: run_command:
'git-upload-pack
'\''/cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.'\'''
13:01:17.136064 run-command.c:195       trace: exec: '/bin/sh' '-c'
'git-upload-pack
'\''/cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.'\'''
'git-upload-pack
'\''/cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.'\'''
13:01:18.084064 run-command.c:336       trace: run_command: 'rev-list'
'--objects' '--stdin' '--not' '--all' '--quiet'
13:01:18.229064 run-command.c:336       trace: run_command: 'rev-list'
'--objects' '--stdin' '--not' '--all'
13:01:18.284064 exec_cmd.c:120          trace: exec: 'git' 'rev-list'
'--objects' '--stdin' '--not' '--all'
13:01:18.314064 git.c:351               trace: built-in: git
'rev-list' '--objects' '--stdin' '--not' '--all'
From /cygdrive/s/StrategyServers/git/gitbmssorsrc.git/.
 * branch            MCSTRATEGY_4_4 -> FETCH_HEAD
13:01:18.367064 run-command.c:952       run_processes_parallel:
preparing to run up to 1 tasks
13:01:18.373064 run-command.c:984       run_processes_parallel: done
13:01:18.375064 run-command.c:336       trace: run_command: 'gc' '--auto'
13:01:18.410064 exec_cmd.c:120          trace: exec: 'git' 'gc' '--auto'
13:01:18.440064 git.c:351               trace: built-in: git 'gc' '--auto'
13:01:18.454064 run-command.c:336       trace: run_command: 'merge' 'FETCH_HEAD'
13:01:18.486064 exec_cmd.c:120          trace: exec: 'git' 'merge' 'FETCH_HEAD'
>> 13:01:18.517064 git.c:351               trace: built-in: git 'merge' 'FETCH_HEAD'
Updating 9c40e07..a0f35eb
Fast-forward
13:18:39.432839 run-command.c:336       trace: run_command: 'gc' '--auto'
13:18:43.559539 exec_cmd.c:120          trace: exec: 'git' 'gc' '--auto'
13:18:43.623539 git.c:351               trace: built-in: git 'gc' '--auto'
 file.cpp | 5 +++--

First question is could this very large delay on git merge be caused
by the noacl?  If noacl is causing this very large delay (which I
suspect to be the case since we didn’t have this large delay till the
noacl was added) is there another way to fix the permission issue when
using an NFS drive as a shared repository?

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