Oh boy
> File system IO functions belong to a class of functions called blocking functions.
Hasn’t non-blocking IO been a major feature for about a decade now??
On some Windows machines with network-mounted drives, the File-Print-to-pdf dialog takes *minutes* to become responsive, even when all currently open files are on a local drive.
This is the kind of thing the author is talking about. The programmers of that dialog box probably just called a generic "open file dialog" library function, without researching its worst-case performance.
In turn the library writers probably blithely coded something like "check if all mounted drives are accessible", without stopping to consider the worst-case performance.
More like the part of Microsoft that implemented non-blocking I/O for Windows some time ago never bothered to tell the part of Microsoft that writes the generic Windows UI code for things like the open file dialog. Or for Microsoft Office applications, for that matter; I still see Word and Excel block the UI thread when opening a file from a network drive, even though Windows has perfectly good asynchronous file I/O API calls.
no, they just don't care.
The alternative to this is to roll a barebones file picker - there might even be one available in the Windows API.
This doesn't make people use it, and even the ones that try to use it might erroneously expect that open(2) will return in less than a second.