From: "Hans-Bernhard Bröker" <HBBroeker@t-online.de>
To: cygwin@cygwin.com
Subject: Re: setup's response to a "corrupt local copy"
Date: Thu, 14 Dec 2017 04:40:00 -0000 [thread overview]
Message-ID: <f4eec91a-1358-cfd1-a3c6-d7dd24836389@t-online.de> (raw)
In-Reply-To: <b06765ec-3d9c-d52b-50c5-7ed22bbb8619@cornell.edu>
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
next prev parent reply other threads:[~2017-12-13 22:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-13 14:36 Ken Brown
2017-12-14 4:40 ` Hans-Bernhard Bröker [this message]
2017-12-14 20:13 ` Andrey Repin
2017-12-14 23:34 ` Ken Brown
2017-12-15 13:05 ` Steven Penny
2017-12-15 14:53 ` Vince Rice
2017-12-16 7:52 ` Steven Penny
2017-12-16 14:40 ` Frank Redeker
2017-12-16 15:33 ` Vince Rice
2017-12-16 20:47 ` Steven Penny
2017-12-16 20:47 ` Ken Brown
2017-12-15 15:20 ` Andrey Repin
2017-12-16 4:00 ` Brian Inglis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f4eec91a-1358-cfd1-a3c6-d7dd24836389@t-online.de \
--to=hbbroeker@t-online.de \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).