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]

Cygwin 1.7.1 breaks git on netapp shared drives


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


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