X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:content-type
	:content-transfer-encoding:date:from:to:subject:message-id; q=
	dns; s=default; b=eBl8EujVRDnXcdw42ZjPvFO3gze65O4Vz0wQmCrLbucpZT
	W2trArxKI+K28C29cg/mnwBnH7hua87wPXXm5gJcC7DpqQqDNqMYToAqMHMd0pwR
	Hn3siTasUgh1TPbbN5USB2I8LTlJboDVlOJzaBbfV4RawbJZefqhRwyBQbmdU=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:content-type
	:content-transfer-encoding:date:from:to:subject:message-id; s=
	default; bh=9pH16ApBfIpy5fjpU8Ve+ycZpW4=; b=ParISun6DyHUTTxCIFQV
	IMVzsGYQsMubGKnFP+z9//dbMtKtC/7dshg+wg51XF4R0lGO5J8qD/Mhp6pOahnJ
	7x5lWyGDdeLsKLiTg1O9eIIeAvYRcavCKg5p4MXn6Phyz/ySQ8BTHGNS4mh9r1oo
	otzTBvWwGtsq2S5MPbO8p24=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
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
Authentication-Results:	sourceware.org; auth=none
X-Spam-SWARE-Status:	No, score=-4.8 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=Package, H*r:194, WRONG, UD:exe
X-HELO:	lb3-smtp-cloud9.xs4all.net
MIME-Version:	1.0
Date:	Sun, 14 Apr 2019 12:41:08 +0200
From:	Houder <houder AT xs4all DOT nl>
To:	cygwin AT cygwin DOT com
Subject:	Setup.exe: BUG.
Message-ID:	<77bf0a487a2ffeb94af5f3fd6264b77e@xs4all.nl>
X-Sender:	houder AT xs4all DOT nl
User-Agent:	XS4ALL Webmail
X-IsSubscribed:	yes

L.S.,

While implementing a solution for the problem described here:

     https://cygwin.com/ml/cygwin/2019-04/msg00032.html
     ( Setup: why consult registry (rootdir) if -R has been specified? )

I discovered a bug in main.cc (setup.exe).

At startup, setup.exe writes the following report to the log file:

yyyy/mm/dd HH:MM:SS Starting cygwin install, version 2.900
yyyy/mm/dd HH:MM:SS User has backup/restore rights
yyyy/mm/dd HH:MM:SS Current Directory: <directory> <====
                     *******
...

The last line above should read:

yyyy/mm/dd HH:MM:SS Local Directory: <directory>, a.k.a. Local Package 
Directory!

The call flow in main.cc is as follows:

Winmain
   main_display

The code in main.cc can be described as follows:

  WinMain
  - local_dir is assigned the current directory (the directory from which
    setup.exe is started)
  - however, at the beginning of main_display the constructor of class
    LocalDirSetting is executed (as result of the declaration of 
localDir)
-
  main_display
  - the constructor of class LocalDirSetting may assign a different value 
to
    local_dir ... (different from the current directory)
    (it is here where I discovered another bug in setup.exe)
-
  - the constructor first checks whether or not option -l has been 
specified
   - using option -l one can specify the local directory a.k.a the Local
     Package Directory, as an argument to setup.exe
  - if option -l has not been specified, the constructor checks if
    the execution of constructor UserSettings (as result of the 
declaration
    of Settings (WinMain) ) has produced a value for "last-cache"
  - "last-cache" (one of the user settings from a previous invocation of
     setup.exe is retrieved from /etc/setup/setup.rc
    - "last cache" is another alias for the local directory a.k.a. the 
Local
      Package Directory
  - CURRENTLY, setup.exe attempts to locate /etc/setup/setup.rc only in
    the root directory as specified by the registry ("rootdir")

Currently? Yes, currently, setup.exe does not attempt to locate the file
in the directory as specified by the -R option (first choice), or in the
current directory (second choice - which would make sense if setup.exe 
is
started in the root directory).

The upshot of the above is, that the report that is written to the 
logfile
is wrong if a different value is assigned to local_dir in main_display.

[ and yes, people do create shortcuts to the setup executable and 
specify
   arguments to the setup program over there. Believe it or not.}

Logging of the current directory should occur in WinMain (see below).

Henri

-----
The code in main.cc as far as it concerns the text above.

static inline void
main_display ()
{
   /* nondisplay classes */
   LocalDirSetting localDir; <====
   SourceSetting SourceSettings;
   ...
// Henri: WRONG! It is the Local Directory a.k.a. the Local Package 
Directory
   Log (LOG_TIMESTAMP) << "Current Directory: " << local_dir << endLog;
   ...
}

int WINAPI
WinMain (HINSTANCE h,
          HINSTANCE hPrevInstance, LPSTR command_line, int cmd_show)
{
   ...
   try {
     ...
     char cwd[MAX_PATH];
     GetCurrentDirectory (MAX_PATH, cwd);
     local_dir = std::string (cwd);
     ...
     ...
     if (!elevate && !output_only)
       {
       ... setup logging ...
// Henri: now you would be right!
Log (LOG_TIMESTAMP) << "WinMain: Current Directory: " << local_dir << 
endLog;
       }
     ...

     if (elevate)
       {
       ... run setup.exe in elevated mode ...
       }
     else
       {
         ...
         UserSettings Settings (local_dir); <====
         main_display ();
         Settings.save ();
         ...
       }
   }
   ... handle exceptions ...
}

=====

--
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

- Raw text -