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]

Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7


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


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