Web lists-archives.com

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