wstat is of course how the MS-DOS, OS/2, and Win32 world has been doing this stuff all along. DosQueryFileInfo() is symmetrical with DosSetFileInfo(). The Win

wstat is of course how the MS-DOS, OS/2, and Win32 world has been doing this stuff all along. DosQueryFileInfo() is symmetrical with DosSetFileInfo(). The Windows NT Native API also has symmetric system calls. Similarly, clonefile is akin (but not identical) to the old DosCopy() system call on OS/2, which likewise made file copying available as a system API call. DosCopy() had the semantics of sending the copy operation over to the file server for actual enactment on (LAN Manager/LAN Server/Netware) remote volumes. And of course Win32 programmers will recognize the result of pdfork that one can give to kqueue, as a process handle that one can give to WaitForMultipleObjects(), although they will be unhappy about the default semantics of closing the process handle. The process descriptor also lacks the ability to poll/select/kevent for stop/continue events in the child process, unlike waitpid/wait6. The point about implementations of fexecve() and execveat() is a good one. For example: If one passes a close-on-exec file descriptor to fexecve() on Linux or FreeBSD, and the executable is actually a script with a #! line, the script interpreter is passed a /dev/fd/N argument for the script that has of course been closed. But if the executable is a binary, the call works fine. Of course, if one reads the first few bytes of the file to find out whether there is a #! line and thus whether the executable is a script or a binary, one needs to open it as O_RDONLY rather than as O_EXEC, thus preventing the execution of files where one does not have read access but does have execute access. One thus ends up opening the executable twice, first with O_RDONLY to check whether it is a script or a binary, and then with O_EXEC to allow a non-readable binary to be executed with fexecve(). kqueue() is good but not ideal. For one example: It has problems if one wants to combine NOTE_TRACK, NOTE_FORK, and NOTE_EXIT, because it returns one event for both a forked child and an exited child, which both try to store different things in the "data" field of the event.