setup-x86_64.exe (bug ?): Cannot write to /usr/bin/cygwin1.dll - cyserver squatting it...
Jon Turney
jon.turney@dronecode.org.uk
Sun Nov 19 22:04:29 GMT 2023
On 16/11/2023 15:50, Bill Sharp via Cygwin wrote:
> On Thu, 16 Nov 2023 at 07:50, Brian Inglis via Cygwin <cygwin@cygwin.com>
> wrote:
>
>> On 2023-11-16 00:03, Martin Wege wrote:
>>> This is not helpful. Cygwin setup-x86-64.exe not being able to update,
>>> because SOMETHING is locking cygwin1.dll is in the top 50 of your IT
>>> support, right followed by the question of IT support whether
>>> "updating to WSL" will solve the situation for them permanently.
>>
>>
>> There may be critical or just really long Cygwin processes running that
>> should
>> not be killed because somebody wants to upgrade.
>>
>> Shutting down processes, including services, has to be left to the users
>> or sys
>> admins who understand whether the circumstances are suitable to kill
>> processes
>> to do an upgrade.
>>
>
>
> I actually agree with both of you to an extent.
>
> However I would like to suggest the correct enchancement here would be for
> setup to check for any running cygwin processes and then barf a warning
> onto the user, referncing the appropriate documentation, before allowing
> them to proceed.
Well, what is supposed to happen at the moment (since [1]), for
processes in the current user's session at least, is better than that -
we check if a file we want to replace is actually in use by a Cygwin
process and offer to terminate that for you.
If that isn't working, that would probably be a bug, and we'd like to
hear about it.
[1] https://cygwin.com/pipermail/cygwin-apps/2013-February/031448.html
I realize this is all well-intentioned, but this discussion is not
actually contributing very much. As always, the difficulty in making
this change is not working out what setup should do, but that someone
has to do it. (A situation unfortunately so common, we have an acronym
for it: [2])
[2] https://cygwin.com/acronyms/#SHTDI
More information about the Cygwin
mailing list