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:reply-to:subject:to:references:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=EK87Os+IyRXhW2ya
	DLByt+ZHIeB7pmAbBx+C6MAF205R08TLigAthPFB93p0+6zxi77m/2GYpJC2iv/h
	rxJ3TkqFiRwTNwbGtDIkc6X5Ftg6SJQwL5ruktTnlo+Vv+bq1/eqILp6mHBnmImq
	yIssRvZNqS8tVR6ggGNBm4DqZjk=
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:reply-to:subject:to:references:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=7UPTSImEBEO59s6u23CvXS
	boVlI=; b=rcVgK455s5UZbQPgS2solGDPXa8zzYH3BzwGxwcsll8vzwz+LCKT5a
	CKRiSIU83KaNz1ee+2oZqd5p1gyHUe1c17oCaWZ6aD84J2ZK9H2UI+7orwB53I2o
	6DvWy2SBBLyShpKMzffwsg57wYZXn4eJz7wCnY8H0CO4krqnnJtTo=
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-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-0.2 required=5.0 tests=AWL,BAYES_40,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=calgary, Calgary, alberta, Alberta
X-HELO:	smtp-out-no.shaw.ca
X-Authority-Analysis:	v=2.2 cv=M/g9E24s c=1 sm=1 tr=0 a=MVEHjbUiAHxQW0jfcDq5EA==:117 a=MVEHjbUiAHxQW0jfcDq5EA==:17 a=N659UExz7-8A:10 a=w_pzkKWiAAAA:8 a=4Rt9iLsgBowfNyw5XZMA:9 a=pILNOxqGKmIA:10 a=RcyqAG5v6fMA:10 a=sRI3_1zDfAgwuvI8zelB:22
Reply-To:	Brian DOT Inglis AT SystematicSw DOT ab DOT ca
Subject:	Re: setup's response to a "corrupt local copy"
To:	cygwin AT cygwin DOT com
References:	<b06765ec-3d9c-d52b-50c5-7ed22bbb8619 AT cornell DOT edu> <116333312 DOT 20171214224616 AT yandex DOT ru> <b031c829-d3a0-f28e-9ce0-0052e7d3475a AT cornell DOT edu>
From:	Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
Message-ID:	<fe4fd62f-e84c-ed61-c39a-cc10a1b4ab0f@SystematicSw.ab.ca>
Date:	Fri, 15 Dec 2017 18:50:39 -0700
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:	<b031c829-d3a0-f28e-9ce0-0052e7d3475a@cornell.edu>
X-CMAE-Envelope:	MS4wfBEsGixhCgdlpLlF90HH8qp5rWShcM33K+bcasZlh2n+5fJnYNRlbDLfdCELnB3Ied5KFMySWHav5X8giKwW3PMQnqaaKyIS23cYXHZkQXWYw/Bn0lbJ mjjHmVwY3X7ADd2VjtCQ/VpbdY48ep7KSE9mL2VnocElrQF9BB3M+s/2IitAMOqdMyLLOQqyHRKgMg==
X-IsSubscribed:	yes

On 2017-12-14 12:57, Ken Brown wrote:
> On 12/14/2017 2:46 PM, Andrey Repin wrote:
>>> This is a followup to the discussion started here:
>>>     https://cygwin.com/ml/cygwin/2017-12/msg00088.html
>>> 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.
>> The point being, if this is a "Download" Setup mode, the files are NOT "User"
>> files, but a local setup cache. And all files therein SHOULD be valid package
>> archives.
>> There's of course situations, when setup.ini on server become corrupted or
>> otherwise out of sync. But being rare, they should not interfere too much.
>>> 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.
>> Make it mode dependent.
>> If it's a "download[ and install]" mode, cleanup and redownload.
>> If redownloaded file still does not match the setup.ini hash or if it's an
>> "install from local cache" mode, leave file alone for investigation and notify
>> the user.
> You've misunderstood the context.  The error is only shown in download or
> download/install mode.  And, as I said, it happens when setup is *preparing* to
> download files and finds a corrupt copy already present in the local cache.  In
> that context, setup has no idea where the file came from.

Setup knows the file came from
	.../%encoded-mirror-url/arch/release/package/.../pvr....tar.xz
so it could warn the user of the validation failure, rename the file failing
validation if the cache is (one of) the currently selected mirror(s) and inform
the user of the rename, then add the package for redo of download/install from
(one of) the currently selected mirror(s), similar to a package prereq.
This would DTRT in most cases and not blow away the questionable cached file.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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