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:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=Nhduueoe2PaIOHD5
	YDKDdGQ2fpttKWhnLUOEA+HPAW32mF4hA//KGGpOSrpqJEJzgAdzwwLeirhM4feh
	s1xYYXpGpAJMGuVm/llSJicVrOkHg7EUkM0IgTC6yHbcINrwTcEHMOv1NXO/XRWg
	SXkxExXKozjPBjKwiGdfGGPLFUs=
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:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; s=default; bh=GEKy2LrjEs93Ax8+DLgjVe
	4jaeo=; b=Jpg6k4t50bBx7w3CjBexZzIz/pxcXCA9yXoATz3arodsaWWjFYEehm
	T38R7k915+Qe1zysxt7W/r7519PA02eCfLR8d/kYxULhBaOmXBF1Hyxv32PQ0BYi
	GZV8JjPc/ZWH4DPdrINQOo38GDO1azQUxKRmdRsoxj74b4lQqqE3k=
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.7 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_THEBAT,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 spammy=H*F:D*yandex.ru, H*M:yandex, HX-Priority:Normal, HTo:D*cornell.edu
X-HELO: forward101j.mail.yandex.net
Authentication-Results: smtp2p.mail.yandex.net; dkim=pass header.i=@yandex.ru
Date: Fri, 15 Dec 2017 15:53:24 +0300
From: Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To: cygwin AT cygwin DOT com
Message-ID: <9810363794.20171215155324@yandex.ru>
To: Ken Brown <kbrown AT cornell DOT edu>, cygwin AT cygwin DOT com
Subject: Re: setup's response to a "corrupt local copy"
In-Reply-To: <b031c829-d3a0-f28e-9ce0-0052e7d3475a@cornell.edu>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

Greetings, Ken Brown!

> On 12/14/2017 2:46 PM, Andrey Repin wrote:
>> Greetings, Ken Brown!
>> 
>>> 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.

Where did I say, when this error is shown currently?

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

Please forget about current behavior and read my post again.


-- 
With best regards,
Andrey Repin
Friday, December 15, 2017 15:44:59

Sorry for my terrible english...


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