X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0	tests=AWL,BAYES_00,TW_RW,TW_WX
X-Spam-Check-By: sourceware.org
Message-ID: <4C7FB49B.70808@bopp.net>
Date: Thu, 02 Sep 2010 09:28:43 -0500
From: Jeremy Bopp <jeremy AT bopp DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
References: <AANLkTima5VbUF2XFvv00ptE1L=9c9BT2hOOM8td4hhUN AT mail DOT gmail DOT com> <AANLkTinZs2FvqFtYueGR0-Wg5L9veTLaE7+SJa56R-r4 AT mail DOT gmail DOT com> <i5li5e$tse$1 AT dough DOT gmane DOT org> <AANLkTi=Z8dSKa6fWt6m2dKMG8gVnG4LEZuq+QN1Y=Qb6 AT mail DOT gmail DOT com> <AANLkTinHHFQSrqJuzhnLzUKLw321Pe2qc=2mkao2Z5iU AT mail DOT gmail DOT com> <AANLkTimzCUXnhekxmjDmmgHgw+ocKt-xBh5Ei=HF5QsB AT mail DOT gmail DOT com> <AANLkTikLOv2xn2RodtrRfgdGnSYYZrMeKyWBfDA67Js1 AT mail DOT gmail DOT com> <AANLkTimBGg8vpw9bFcbzvaieTv5DvOSbK5ytJnpLcVP0 AT mail DOT gmail DOT com> <AANLkTimFJS7THKkUa76rBMWkQWYpe5r=p3prETQgqymv AT mail DOT gmail DOT com> <AANLkTi=zev2TeGMvk1fxkx8e8xVRW9J2V5JP7C3S72Bt AT mail DOT gmail DOT com>
In-Reply-To: <AANLkTi=zev2TeGMvk1fxkx8e8xVRW9J2V5JP7C3S72Bt@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
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 9/2/2010 12:49 AM, Vasya Pupkin wrote:
> No, it wasn't a mess of my own making. I did not ever touch
> permissions, and it was a clean install. I don't know where these
> permissions came from, but ls -l displayed something like that for
> most files:

I read Andy's comment to mean that the mess of your own making is the
result of you changing the permissions, not the existing permissions as
left by setup.exe.  You made the mess (or correction as you see it) and
are now fighting with setup.exe to maintain it.

> drwxr-xr-x+ 1 user group      0 2010-09-02 09:32 tests
> 
> This "+" sign after permissions string indicated non-cygwin
> permissions which was impossible to remove using cygwin's chmod. And
> since permissions are not inherited, it was not possible to mass
> remove them using windows either. So, I just removed all permissions
> and forced their inheritance. That solved all problems, until I
> updated installation using setup.exe.

The "+" indicates that there are further permissions specified as ACLs
for which the getfacl and setfacl commands should be used to view and
manipulate, respectively.  You would see the same behavior from ls on a
Linux system which had ACL support and extra ACLs applied to a similar
file or directory.  There, too, chmod would not be able to modify those
ACLs.

What your example does not indicate is that anything unintentional
happened with the application of permissions on that example directory.
 Nor does it indicate that the given permissions are in any way harmful
to the maintenance of your system or the use of the files and
directories in question.

Where was that directory located?  Did you create it, or did setup.exe
create it?  What problems do those permissions cause?

> Believe me or not, but I really did not touch any permissions until I
> noticed that strange behaviour. And I am the only administrator.
> Machine is not a part of any domains. So, unless it's a kind of black
> magic, there was (and maybe still is) some issue with permissions in
> cygwin. That is why I don't want to use them.

I'm sure the Cygwin developers would be more than willing to patch any
defect surrounding the incorrect application of permissions to files
which is the result of Cygwin itself or setup.exe.  Unfortunately, you
have not demonstrated any such erroneous behavior yet.  It seems more
likely that you have a small misunderstanding about how the permissions
you see work and how they are represented under Cygwin.  Have you read
the section of the user guide which discusses permissions under Cygwin?

Perhaps, you have found a genuine defect.  If so, you need to provide
more data so that someone else can reproduce the problem.  You could
start by installing another instance of Cygwin into a fresh directory
(this won't affect your primary installation) and then demonstrate the
specific files that have faulty permissions and explain how those
permissions will lead to further problems.

With luck, someone will be able to explain why things are the way you
see them such that you are comfortable accepting how Cygwin does things. :-)

-Jeremy

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