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: List-Subscribe: List-Archive: List-Post: List-Help: , 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 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 14 Apr 2019 12:41:08 +0200 From: Houder 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: <==== ******* ... The last line above should read: yyyy/mm/dd HH:MM:SS Local 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