Re: setup's response to a "corrupt local copy"

[Hans-Bernhard Bröker <HBBroeker at t-online dot de>]

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