Windows explorer unzip is even worse. Recently in a VM I tried unzipping boost 1.62.0 using explorer in Windows 10. It said it would take over 3 hours. The same file was decompressed on the command line in about a minute using 7zip on the same VM.
Windows also always unzips to a fixed scratch directory before creating the real files.
That scratch directory is %TMP% or %TEMP%, I think, but it definitely always is on the same disk, typically C:
If you unzip files to another disk than where that directory lives, it unzips to its scratch directory, then _copies_ the extracted files to their destination, and finally deletes the scratch files.
That's bad in itself, but doubly so if the disk where it unpacks doesn't have room for the unzipped files.
Mac OS had a system call "Give me the temp directory on this disk" (FindFolder) that made it possible to extract to a temp directory and then move the result to the destination. That call made it into Carbon. I don't think macOS still has it, but it seems UnArchiver does the right thing, anyways.
Internet explorer did the same thing with downloads; I discovered this when I had a 1GB C: drive and a 6GB D: drive and tried to download something that was too large to fit on the C: drive.
For a tool that's supposed to be on most desktops by default, Explorer has some strange inefficiencies, such as the estimation and the loooong "preparing to copy" phase. Perhaps they are carried over from the old Windows NT codebase?
