Running “sfc /scannow” should fix it (i.e. restore the original binary) in the case of curl.exe being deleted, and (optionally) an updated binary copied into its place.
On the other hand, if you overwrote curl.exe with an updated version you’ve now corrupted the Windows component store (aka. WinSxS). Almost all Windows system files are actually hard links to the file in the component store and curl.exe is no exception:
fsutil hardlink list C:\Windows\System32\curl.exe
\Windows\System32\curl.exe
\Windows\WinSxS\amd64_curl_31bf3856ad364e35_10.0.22621.1555_none_5e4b2bfa98c5c82b\curl.exe
In which case you’ll need to repair the component store first with “dism /Online /Cleanup-Image /RestoreHealth” and then run “sfc /scannow”.
Anyone who’s actually modified the curl.exe binary has already had to jump through at least a couple of hoops. Administrators by default can’t modify the file, you’d have to take ownership of the file then grant yourself write permissions. This stops at least “casual” modification of system files, which is to say, if you’ve gone so far as to override ownership of the file, modify its ACL, and then replace it, you’re supposed to know what you’re doing.
So some people invested enough time into a bunch of wrong choices, bricked their system and then complained loud enough that the curl author had to talk about it.
In general this is a case of an Operating System’s protections running afoul of third party tools and their “protections”. I’ll leave the, who is at fault discussion, as an exercise for the reader but it’s definitely not the Curl project.
If I were MS I would be considering some way to limit the damage these tools do to their reputation but I’m honestly not sure what they can do that won’t get branded as heavy handed or anti-competitive.
Running “
sfc /scannow” should fix it (i.e. restore the original binary) in the case ofcurl.exebeing deleted, and (optionally) an updated binary copied into its place.On the other hand, if you overwrote
curl.exewith an updated version you’ve now corrupted the Windows component store (aka.WinSxS). Almost all Windows system files are actually hard links to the file in the component store andcurl.exeis no exception:In which case you’ll need to repair the component store first with “
dism /Online /Cleanup-Image /RestoreHealth” and then run “sfc /scannow”.Anyone who’s actually modified the
curl.exebinary has already had to jump through at least a couple of hoops. Administrators by default can’t modify the file, you’d have to take ownership of the file then grant yourself write permissions. This stops at least “casual” modification of system files, which is to say, if you’ve gone so far as to override ownership of the file, modify its ACL, and then replace it, you’re supposed to know what you’re doing.So some people invested enough time into a bunch of wrong choices, bricked their system and then complained loud enough that the curl author had to talk about it.
TIL Windows comes with curl!
ssh too!
In general this is a case of an Operating System’s protections running afoul of third party tools and their “protections”. I’ll leave the, who is at fault discussion, as an exercise for the reader but it’s definitely not the Curl project.
If I were MS I would be considering some way to limit the damage these tools do to their reputation but I’m honestly not sure what they can do that won’t get branded as heavy handed or anti-competitive.