This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: Problems with autoconf-2.52 testsuite using current CVS Cygwin
- To: Charles Wilson <cwilson at ece dot gatech dot edu>
- Subject: Re: Problems with autoconf-2.52 testsuite using current CVS Cygwin
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- Date: Sat, 04 Aug 2001 14:09:19 -0400
- CC: cygwin-developers at sources dot redhat dot com
- References: <996329431.27668.ezmlm@sources.redhat.com> <3B63432E.6050309@ece.gatech.edu> <3B649305.2090302@ece.gatech.edu> <3B64C0A9.1080700@ece.gatech.edu> <3B64F567.6060304@ece.gatech.edu> <3B65835C.9000001@ece.gatech.edu> <3B65A2B8.90702@ece.gatech.edu> <3B66CC47.8040704@ece.gatech.edu> <3B6711C9.6050700@ece.gatech.edu>
Chris Faylor wrote:
>>Ok. We seem to be slowly zeroing in on the problem. Is someone willing
>>to debug what's going on? Why are the files deleted with
>>VFORK/no-vfork?
>>
>>Has anyone tried turning off VFORK in cygwin and seeing if that solves
>>the problem, too?
>>
>>We need to understand what mechanism is not being triggered to delete these
>>files.
>
>
> Anyone working on this? I'd like to make a new release someday and this
> should obviously be fixed.
>
> It would be wonderful if I didn't have to actually load the newest version
> of autoconf on my system and debug this after all of the previous debugging
> attempts.
Oops. It dropped off my radar screen. I'll try to take a look, but I'm
running out of time. At the risk of sounding like Bobby, Jr. <g>:
My main development machine (a laptop) has had a mechanical failure, so
I have to ship it off to Dell for repair on Monday. It looks like I'll
be dead in the water for about a week after that. I will have email
access(*) via other machines, but none of those are setup for cygwin
devel. Or for LaTeX dissertation editing, for that matter. :-(
(*) except that we're upgrading our mail/file server at the lab Sunday,
so I'll be out of email contact Sunday night and Monday AM, as well.
<on a different note, see below>
Charles Wilson wrote:
> so the following *should* do the trick (assuming mktemp exists, of
> course). I'm only concerned with removing "inheritance" from a single
> parent directory.
>
> #!/bin/sh
> foo=`mktemp -d /tmp/ggXXXXXX`
> if [ -d ${foo} ] ; then
> if [ -d $1 ] ; then
> chmod --reference=$1 ${foo} # save old value
> chmod 0777 $1 # hopefully this is different
> chmod --reference=${foo} $1 # restore old value
> fi
> rmdir ${foo}
> fi
I've been using this script, lately. So far, few problems, BUT (a) it's
specific to the problems on my system, and (b) I may be removing ACL's
that are actually needed. I may also need to go back and add an ACL for
group SYSTEM. I dunno. We'll see.
#!/bin/sh
# symbolic links are neither -d or -f.
if [ -d $1 ] ; then
setfacl -d g:544,u:500,d:g:544,d:u:500 $1
setfacl -d g:545,u:1000,d:g:545,d:u:1000 $1
foo=`mktemp -d /tmp/ggXXXXXX`
if [ -d $foo ] ; then
chmod --reference=$1 $foo
chmod 0777 $1
chmod 0775 $1 # force a change
chmod --reference=$foo $1
rmdir $foo
fi
else
if [ -f $1 ] ; then
setfacl -d g:544,u:500 $1
setfacl -d g:545,u:1000 $1
foo=`mktemp /tmp/ffXXXXXX`
if [ -f $foo ] ; then
chmod --reference=$1 $foo
chmod 0777 $1
chmod 0775 $1 # force a change
chmod --reference=$foo $1
rm -f $foo
fi
fi
fi
I've been calling it thus:
for fn in `find . -name "*"` ; do
echo $fn
fixacl $fn
done
On various subtrees.
--Chuck