Apt cyg error updating setup ini
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.
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.
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.
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".
" 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_!!??! -- Problem reports: info: it doesn't know where they came from.As Hans said: viewpoint would be in concert with a typical "Git" workflow: 1. add those changes to the index with step 2 being the analogue to creating a custom should always have the final say on what a correct file is; so if you want a custom archive then you better tell about it or otherwise risk it being nuked.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.
Additionally, as suggested by cyg Simple, there could be an option that directs setup to silently remove corrupt files.