Message-ID: <4B624299.1050806@comcast.net>
Date: Thu, 28 Jan 2010 20:06:17 -0600
From: Steve Bray <scbray AT comcast DOT net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.1
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Cygwin 1.7.1 breaks git on netapp shared drives
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

> On Jan 27 20:33, Steve Bray wrote:
> >  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".
> >  [...]
> >  With Cygwin 1.71, chmod fails.  For some reason "ls -l" shows no
> >  permissions.  I can create, read, write, and remove files.
>
> There's only one reason for chmod to fail.  Apparently your netapp drive
> reports to have persistent ACLs but then returns an error when trying to
> set an ACL.  It's incredible how many broken filesystems are out in the
> wild.
>
> Please run the /usr/share/csih/getVolInfo tool on the drive and
> pate the output into your reply.
>
> Did you try to strace chmod to see what happens?
>
> Last but not least, did you try to mount the drive with the noacl
> option?http://cygwin.com/cygwin-ug-net/using.html#mount-table
>
>
> Corinna

git, ls, and chmod  are functional after mounting with the noacl option 
and git correctly sets the R/O bit.

My perspective:

The permissions on the shared drive are not consistent with POSIX but 
appear to be the correct permissions to control a Windows shared drive.

My observation of managed Windows shared drives:

- Users have access as members of a group.
- This group does NOT have NTFS "Change Permission" so users can NOT 
change ACEs.
- The Windows cacls will fail to make changes.
- Cygwin 1.7 chmod will fail and git will fail (unless explicitly 
mounted as noacl).
- Cygwin 1.5 chmod and git did not fail.  It may have ignored the ACEs 
and assumed FAT/FAT32.

I would not characterize this as a broken filesystem:

- Organizations often have many shared drives and each is restricted to 
a controlled group of users.
- Access would not be controlled if any user in the group could change 
the ACEs.

This may be a typical Windows shared drive but is not a typical POSIX 
filesystem:

- Unlike POSIX, a user of this Windows shared drive can NOT change 
permissions on the files created and owned.

So I can proceed by explicitly mounting shared drives with the noacl option.

However, since acl is the default and these are common permissions on a 
shared drive, I suspect that I and others will continue to have commands 
fail.

I hesitate to propose more complication, but could it automatically 
revert to noacl (FAT/FAT32) and ignore ACEs when the user has no 
permission to change them?

Much thanks.  We now have a way to use Cygwin 1.7.

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