Throughout the CoreFoundation framework source, POSIX filesystem API calls (e.g.
[t]his file is a special device that's monitored by the autofs
filesystem implementation in the kernel. When opened, the autofs
filesystem will not block that process on any I/O operations on an
autofs file system.
These devices allowed the implementor(s) to avoid to define a new
ioctl for the functionality, and maybe it was implemented that way because it was simpler, requires updating less code, and does not change the VFS API, which may have been the concerns at the time.
When you open
/dev/autofs_nowait and traverse a path, you trigger auto-mounts, but don't wait for them to finish (otherwise your process blocks until the filesystem is mounted or after the operation times out), so you may receive a
ENOENT when opening a file even if everything goes fine.
/dev/autofs_notrigger makes the process not even trigger the auto-mounting.
That is all those devices do. The thing is that, in Darwin's implementation,
open may block when traversing the filesystem even with
You can follow the flow from the vfs, from the
open operation of a
Down that path there's no handling of the (non)blocking behavior.