Cygwin 1.7.1 breaks git on netapp shared drives

Steve Bray scbray@comcast.net
Thu Jan 28 10:19:00 GMT 2010


This looks similar to the December 16 thread "Cygwin 1.7 beta breaks git 
on Windows shares"
and may be related to the thread "chmod and DOS vs POSIX paths".

Note that the Cygwin 1.7 changes in permission handling could break 
other applications that attempt to change permissions on netapp files.

Several teams have been using shared master git repositories on a netapp 
(as shown in mount) shared drive (ntfs) with Cygwin 1.5 and Windows XP.  
With Cygwin 1.7.1, all operations that should create git objects fail 
with the same error reported in the prior thread:

        error: unable to set permission to
'.git/objects/25/7cc5642cb1a054f08cc83f2d943e56fd3ebe99'

The line of code in git has just created the new file and is attempting 
to remove write permission.  The attempt to set mode 0444 fails and the 
operation is aborted.  With 1.7.1 we can no longer add any content to 
these repositories (push, add, etc.).

I compared direct use of chmod on these drives.  Cygwin 1.5 can change 
the r/o flag.  I do not think it changed any ACEs.  It never returned an 
error.  This is not correct but git can function.

With Cygwin 1.71, chmod fails.  For some reason "ls -l" shows no 
permissions.  I can create, read, write, and remove files.

The git failure is consistent for multiple users and multiple netapp shares.

The Cygwin documentation and FAQ appear consistent with this change in 
permission handling although it is not clear if chmod fails because a 
netapp mount is handled as FAT/FAT32 or it failed in an attempt to 
change the NTFS ACEs.

Note that we do not have permission to change the file permissions.  The 
IT department controls access with a group and does correctly prevents 
users from compromising security.  Cygwin would not be able to change 
ACEs.  We can set the R/O flag and Cygwin could achieve this affect but 
I understand the other considerations.

So with the 1.7 changes, it now correctly reports the failure to change 
permissions but on a POSIX system an application should be able to set 
the permissions on a file that it just created and owns (SELINIX 
ignored).  This change will likely break more that git.  We were forced 
to move back to Cygwin 1.5.  With the strong warning not to stay on 1.5, 
we do not have a Cygwin path.

I greatly appreciate the phenomenal progress toward putting a POSIX face 
on many flavours of Windows.  This appears to be yet another trade-off 
to minimize the effect of differences.

Steve

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



More information about the Cygwin mailing list