X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS
X-Spam-Check-By:	sourceware.org
To:	cygwin AT cygwin DOT com
From:	Steve Bray <steve4578 AT comcast DOT net>
Subject:	Re: Cygwin 1.7.1 breaks git on netapp shared drives
Date:	Thu, 25 Mar 2010 07:17:59 -0500
Lines:	52
Message-ID:	<hofk9o$8bg$1@dough.gmane.org>
References:	<608157 DOT 47595 DOT qm AT web110616 DOT mail DOT gq1 DOT yahoo DOT com> <hnpcg5$fls$1 AT dough DOT gmane DOT org> <747800 DOT 43893 DOT qm AT web110615 DOT mail DOT gq1 DOT yahoo DOT com> <20100324091522 DOT GS32321 AT calimero DOT vinschen DOT de>
Mime-Version:	1.0
User-Agent:	Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.3
In-Reply-To:	<20100324091522.GS32321@calimero.vinschen.de>
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

On 03/24/2010 04:15 AM, Corinna Vinschen wrote:
> On Mar 23 16:37, Chris Idou wrote:
>>
>>
>> After a heck of lot of screwing around, I got this mount point stuff working. Now when I create files under cygwin they have the same permissions profile as they do when I create them under windows.
>>
>> BUT...
>>
>> git doesn't work still. It fails with the exact same error of "unable to set permission". How do the cygwin APIs work under noacl? They shouldn't ever return error code should they?
>
> They should.  There's the one case in which you're trying something like
> chmod 444.  Under noacl conditions this sets the DOS R/O attribute.  If
> that fails, the call fails.
>
>
> Corinna
>
In my original post I acknowledged that we can not make NTFS ACLS 
exactly match POSIX behavior.  The best that we can do is consider the 
impact of our choices.

The cygwin 1.5 behaviour often failed to report chmod failures but many 
of us have been happily using cygwin for a long time and never noticed.

With cygwin 1.7 the trade-offs in handling NTFS ACLS were changed. 
chmod failures are now reported but now chmod fails unless the user has 
NTFS ACLS that support changing permissions.  All of the Windows shared 
drives, that are secured, do not give users permission to change 
permissions on the files that they create and own.  This does not occur 
on POSIX.  Application like git and svn will fail.  The following will fail:

$ echo foo stuff > foo
$ chmod 444 foo


In our case we still had permissions on our shared drive to write 
attributes and extended attributes.  In any case, after mounting with 
noacl git can change the RO flag and is functional.

I was not able to test a condition that blocked changing the RO flag.
I removed ACLS for write attibutes, write extended attributes (and 
change permissions) but chmod and git were still able to set the files 
RO.  My permissions might be leaking through in some way.  I have only 
one account and limited permissions to do much investigation.

If Chris is in an organization that removes permission to change either 
ACLS or the RO flag, then how does he use cygwin and git?

Thanks in advance for any help.  Putting a POSIX face on Windows is 
truly a daunting task.




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

- Raw text -