From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122920 invoked by alias); 13 Dec 2017 22:54:31 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 122912 invoked by uid 89); 13 Dec 2017 22:54:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=odds, timestamps, solved, Hx-languages-length:2990 X-HELO: mailout04.t-online.de Received: from mailout04.t-online.de (HELO mailout04.t-online.de) (194.25.134.18) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Dec 2017 22:54:29 +0000 Received: from fwd38.aul.t-online.de (fwd38.aul.t-online.de [172.20.26.138]) by mailout04.t-online.de (Postfix) with SMTP id A60A841B11A8 for ; Wed, 13 Dec 2017 23:54:26 +0100 (CET) Received: from [192.168.2.28] (Gz+n3BZ-gh54-ys1KSMskeavqkeFEJhqk0xs21GXbKx82JGWhliEoUStj9KZN4xZFT@[91.59.8.169]) by fwd38.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1ePFuz-17eK2a0; Wed, 13 Dec 2017 23:54:25 +0100 Subject: Re: setup's response to a "corrupt local copy" To: cygwin@cygwin.com References: From: =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= Message-ID: Date: Thu, 14 Dec 2017 04:40:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00128.txt.bz2 Am 13.12.2017 um 14:28 schrieb Ken Brown: > When setup is preparing to download files and it finds a corrupt copy in > the local cache, it issues a fatal error message telling the user to > remove the corrupt file and retry.  Steven said that setup should > silently delete the corrupt file, while I argued in favor of the current > behavior, on the grounds that setup shouldn't be deleting user files if > it doesn't know where they came from. I agree with the latter approach, primarily because those files must have still been OK the last time setup was run successfully, or not have been there at all. Otherwise this run of setup wouldn't be the one where this suddenly popped up, would it. So the real question is: how could that status have changed from then to now? First off, I hope we agree that files very rarely change their content just by lying around somewhere, particularly in a local cache folder structure like this, which will usually not be touched by anything other than setup itself. So the odds should really be negligible that the files just corrupted themselves. If those are sizable odds on a given machine, the ease of further cygwin installs done onto it are the least of your worries. That leaves two primary possibilities how this change of state might have occurred: 1) File contents changed on purpose, probably by manual overwrite with locally built archives. 2) setup's idea of what a correct file is changed from one run of setup.exe to the next, mostly likely by loading a newer setup.ini > There is a middle ground: setup could query the user.  Additionally, as > suggested by cyg Simple, there could be an option that directs setup to > silently remove corrupt files. I agree: this is essentially the same situation as a merge conflict in CVS/SVN/git: upstream (setup.ini) and local working copy (archive) are now in conflict, and you really _have_to_ ask the user about what to do about it. The query should contain relevant details (CRC expected vs. observed, timestamps, whatever) to allow the user to make an informed decision, and it might better offer an extra wide selection of answers, such as Back to selection, Delete this, Delete all, Keep this, Keep all, and possibly even "Back up local file for later inspection". A command line switch really won't do, because its setting would be decided either way too early or slightly too late for that decision to have any reliable relation to what the user needs to happen in the case at hand. It would unavoidably trigger irate user feedback like "This switch solved some arcane problem I don't even remember any more, years ago, so I hardcoded it in the start script; and _now_ you tell me that's what killed my local, irreplacable cygwin packages?" one way, or "If just some junk file needed to be deleted, why on earth does that mean I have to step through that entire, tedious setup and package selection _again_!!??!@" the other. -- 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