Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
X-Envelope-Sender-Is: Andrej DOT Borsenkow AT mow DOT siemens DOT ru (at relayer david.siemens.de)
Date: Sat, 2 Jun 2001 22:02:41 +0400 (MSD)
From: Andrej Borsenkow <Andrej DOT Borsenkow AT mow DOT siemens DOT ru>
X-X-Sender:  <bor AT itsrm2 DOT mow DOT siemens DOT ru>
To: Corinna Vinschen <cygwin AT cygwin DOT com>
Subject: Re: ntsec and shell script problem
In-Reply-To: <20010602172654.R595@cygbert.vinschen.de>
Message-ID: <Pine.SV4.4.33.0106022155110.27900-100000@itsrm2.mow.siemens.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 2 Jun 2001, Corinna Vinschen wrote:

> On Sat, Jun 02, 2001 at 11:11:48PM +1000, Robert Collins wrote:
> > This is just a bug report, I've got no suggestions on a fix just now :[
> >
> > problem: auto generated files, such as config.status and the libtool
> > script, are create with permisions
> > -rw-rw-rw-, not
> > -rwxrwxrwx.
> >
> > my
> > CYGWIN=$'ntsec binmode'
> >
> > Background: I'm looking into why libtool is currently broken, and one of
> > the problems is that the libtool script is created without execute
> > permissions.
> >
> > My suspicion is that the files are checked by cygwin for #!/bin/foo at
> > create time, (which will fail as len==0), set to rw-rw-rw-. IMO the
> > correct behaviour should be to set the x bit on all files when they are
> > created, as long as it would be inherited from the directory above (I've
> > included a ls -al for reference), and not touch the x bit unless a
> > userland program calls chmod.
>
> No, that's not correct. Files are created using the permission
> bits used in the applications call to creat(2) or open(2), just
> modified by the current umask. It's not the responsibility of
> Cygwin to change modes and it will not do it. That has nothing to
> do with ntsec and as long as ntsec is switched on, the permissions
> are only generated as it's usual on POSIX systems. There's no
> code which checks for the content in any way to change the
> permissions on create time.
>

It has something to do with ntea (and being on Win2k, I have ntsec
anyway). If ntea is set I get the above problem.

1. x-bit is reset after writing to file. I.e.

touch foo
chmod +x foo
echo > foo

will reset x-bit. Most Unix scripts assume that it is possible.

2. I had the above problem (config.status lost x-bits) with zsh configure
script. I added chmod +x after every change in config.status. I added ls
-l config.status to several places in configure (including just before
exiting). Result - immediately at the end of configure ls -l reports
config.status with x-bit. ls -l after configure run shows config.status
without x-bit.

It may be related to the 1 above - if configure holds config.status open
for writing and Cygwin resets x-bit on file close when ntea is set ...
just speculating.

I cannot provide actual logs currently, but will do it on Monday if you
are interested.


> Did you look into libtool if the script is actually created using
> x-bits or if a chmod is called on the file which perhaps fails?
>

Yes, see above. It is O.K. inside script - the problem comes when script
ends :-)

-andrej


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple