X-Spam-Check-By: sourceware.org
Message-ID: <43A9B525.D6583A4B@dessent.net>
Date: Wed, 21 Dec 2005 12:03:49 -0800
From: Brian Dessent <brian AT dessent DOT net>
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Execute bit getting set on created files when it shouldn't
References: <43A9B2B9 DOT 7080809 AT gdssw DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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

Don Peterson wrote:

> Problem statement:  running a non-cygwin program in a console generate
> files with the execute bit set, even if your umask doesn't allow it.

Why would a non-cygwin process have any concept of 'umask', let alone
respect its setting?  This is entirely a Cygwin mechanism.

This is purely due to NTFS permissions, as most applications do not
specify an ACL when creating a file, they just inherit the ACL of the
directory or its parent, and so on.  If you don't want the execute bit
set, then change the ACL of the filesystem object from which everything
is inheriting.  However, expect this to break most windows programs (or
at least their installers), since the notion of having to explicitly set
the execute permission on binaries does not exist on windows.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/