Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Subject: RE: Setup 2.218.2.4 (fixed?)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Tue, 14 May 2002 21:34:24 +1000
content-class: urn:content-classes:message
Message-ID: <FC169E059D1A0442A04C40F86D9BA7600C60AE@itdomain003.itdomain.net.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-apps AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g4EBYX624691


> -----Original Message-----
> From: Christopher Faylor [mailto:cgf AT redhat DOT com] 
> Sent: Tuesday, May 14, 2002 2:57 PM
> To: cygwin-apps AT cygwin DOT com
> Subject: Re: Setup 2.218.2.4 (fixed?)
> 
> 
> On Mon, May 13, 2002 at 12:19:41PM -0400, Christopher Faylor wrote:
> >On Mon, May 13, 2002 at 09:05:52PM +1000, Robert Collins wrote:
> >>>I've noticed the same problem on a non-smb directory, fwiw.
> >>
> >>dir you mean as in "d:\foo" or as in NFS mounted?
> >
> >Occam's razor.
> 
> I think I've tracked this problem down.  I've checked in a 
> couple of fixes in the branch.  I've put up a new version of 
> setup.exe on sourceware.

Thanks. Somehow your version grabs atoi from cygwin1.dll. Doh. I'm about
to upload a new version.
 
> I believe that there were a couple of problems.  One was that 
> setup.exe would consider anything with the string "setup.ini" 
> to be a potential setup.ini file.  The reason for this is 
> that Robert (or someone) seems enamored of the use of strstr 
> for path manipulation.  I think I've mentioned before that 
> you really can't do a strstr (path, "foo.bar") and assume 
> that any foo.bar that means that the file component is 
> "foo.bar". This assumption exists in several places in the 
> source code.

Yeah, it was on my this-is-not-quite-right list, but I didn't think it
could be causing the crashes..
 
> In my case, setup.exe was parsing files like setup.ini.old, 
> setup.ini~, and setup.ini.orig.  This caused problems since 
> the assumption was that the setup.ini was the trailing 
> component of a path spec, which it wasn't.

Ah, so the trailing path was calculated as ...setup/ (given
setup.ini.orig).
 
> The other problem was the clobbering of a global buffer.  
> This resulted in either a stack overrun or just a hung setup.exe.
> 
> I've attached the patch and ChangeLog below.  I didn't try to 
> check this into the trunk since I thought that Robert would 
> look at it and want to do something another way.

I might, but in no great rush. If you've got the time, please port this
forward.
 
> Can I suggest that probably setup.exe needs something like a 
> "suffix" function which operates similarly to strstr but only 
> returns a non-NULL pointer if the string matches the last 
> strlen(string) characters of a path?

The STL provides rfind, and suffix could be created as a semi-trivial
wrapper of rfind.

Thanks for this Chris.

Rob