Re: setup's response to a "corrupt local copy"
- Date: Wed, 13 Dec 2017 23:54:01 +0100
- From: Hans-Bernhard Bröker <HBBroeker@xxxxxxxxxxx>
- Subject: Re: setup's response to a "corrupt local copy"
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
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
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple