[Disclaimer: I set out for a short, two or three paragraph response, but this spiralled out of control. Sorry, everyone.]
I used to resort to terminal commands when using Tiger/Leopard at my old job. Once you got the beach ball after ejecting a server share, force quitting Finder meant it would not restart - which meant rebooting. You could wait for the beachball to stop, but you'd be there for hours and most times it was just hung.
Now, my reaction to an eject that won't happen is to disconnect from the network or pull a plug from a drive. It's ugly, but most of the time it prevents a reboot.
I’d hazard to guess (as I haven’t definitively found documentation verifying this) the LAN-facing process to leave Finder and file system access from WindowServer hanging when eject aren’t happening when desired — and the phenom, post-Snow Leopard, of
long hangs after waiting for the system to draw up an application list when right-clicking “Open with…” — are probably rooted in shared origin.
At some point during macOS development, Apple developers refined or changed an essential background process to depend a lot more heavily on what other Macs on the local network have/are doing
before releasing activity locally on a system being controlled physically by the user — a kind of network- or server-priority to how the OS functions. (A network-/server-priority departs from a local-/client-priority of, say, making a volume eject a more cumbersome affair now than it once was.)
I don’t have a ready way to test the precise moment this behaviour changed (OS or hardware-wise), or to pinpoint which process it is (without doing a lot of tail process debugging-level logging). The rough contours of when the “Force eject…”/timing-out dialogue of a stubborn volume arrived to macOS (whether local-physical being shared on the LAN or a network-attached volume), appeared not terribly long before the “Open with…” LAN-polling long delays began to emerge as a quote-unquote normal behaviour.
Forever-hangs (like those bedraggling Tiger and Leopard users like you’re describing here) might have been something Apple wanted to limit after fielding user feedback (including their own internal testing) which complained of watching an I/O error of a failing HDD or a hanging network volume
de facto bringing down the whole system.
[Even so, in Snow Leopard, “Force eject…” was a new arrival — possibly part of the Cocoa Finder re-write. The “Open with…” hang, however, arrived sometime
after Snow Leopard (that is: I’ve never successfully replicated the “Open with…” hang-delay on
any SL Mac ever), as Snow Leopard and earlier don’t try to poll other LAN-connected Macs to find suitable application candidates to add to an “Open with…” list.]
LAN polling delays of “Open with…” may also speak to one’s own home network (and/or if any devices are connected at low-bitrate, as distal devices on the edge of a wifi network or legacy PowerPC Macs are negotiating at 10/100 Base-T Ethernet speeds).
The thing about this behaviour to perplex me is an insistence that network-dependent priority is something Mac users desire, without an opt-in/out feature (even an advanced one buried in an OnyX toggle), in Apple’s “it just works” objective. Also, that people would still think to open a LAN-located application over a local one may be a carryover from the Mac OS era, but a network-launched, “LAN-cloud” application is still going to be a slower experience, even on fast local networks.
The prevalence of “[Volume] couldn’t be ejected because [another application] is using it” or “[Volume]” isn’t ejecting properly” may be to prevent users from suddenly losing work on, say, a project (whose file is on an ejecting volume). That Apple didn’t bother to feature a Finder dialogue warning similar to “Force eject…”, but warning how “[an open file] in [application] may lose data by force-ejecting [volume]”, yet giving them the option to do it anyway, is what I find perplexing — and, at particular times, annoying.
Anyhow,
tl;dr: I pepper this with a lot of “may” qualifiers. It means getting to the root of which process was changed to behave in these manners are still unknown (to me, at least).
www.zanjero.de
