DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:to:from:subject:message-id:date:mime-version
	:content-type:content-transfer-encoding; q=dns; s=default; b=sou
	W7XDhv/4NvHpPbezLctpyzW050BNgH/DaKp436JxDz4Y0SJSlxyv27qGDsiot53f
	V4C+GzycaTRh4hua5UYymru005r94XkGO3aFc8o6SdBMiybEyFXpa2nRZBk0Ew+O
	Urzw9SSzfxvaNKWO7jcbLdwnKK6zrqIe0av9cHNs=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
To: cygwin <cygwin@cygwin.com>
From: Ken Brown <kbrown@cornell.edu>
Subject: setup's response to a "corrupt local copy"
Message-ID: <b06765ec-3d9c-d52b-50c5-7ed22bbb8619@cornell.edu>
Date: Wed, 13 Dec 2017 08:28:00 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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.

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.

Ken

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