www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2010/01/28/21:06:34

X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
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
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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 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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019