DIrectory handles versus directory-listing handles (and procedure naming) Lassi Kortela 11 Dec 2019 13:03 UTC
> Looking at the glibc code, it really and truly opens the directory as a file Note that opendir() does not portably return a file descriptor. And AFAIK there's no documented way to get a file handle from the search handle returned by the WinAPI FindFirstFile() function. Therefore the SRFI has to treat opendir("/some/dir") and open("/some/dir") as fundamentally different operations. Hence to avoid confusion, open-directory and close-directory should be called something else. R6RS has the following procedures: - (get-u8 port) - (get-bytevector-n port count) - (get-bytevector-some port) - (get-bytevector-all port) We could have: - (open-directory-list path/port/fd) => handle - (read-directory handle) - (read-directory-n handle count) - (read-directory-some handle count) - (read-directory-all handle) - (close-directory-list handle) It turns out that read-directory-all is basically equivalent to `directory-files` (if it returns a list instead of a vector - it's up for debate which type the results should be). IMHO `read-directory-some` is nice since it's the easiest to optimize (with regards to buffering and locking) for scenarios where performance really counts. As for (open "/some/directory"), Linux and some BSDs have an O_DIRECTORY flag to ensure that open() only opens a directory, not a regular file.