Directory listings, continued Lassi Kortela 10 Dec 2019 21:19 UTC
Re: Directory listings, continued Lassi Kortela 10 Dec 2019 21:22 UTC
Re: Directory listings, continued John Cowan 10 Dec 2019 22:41 UTC
Re: Directory listings, continued Lassi Kortela 10 Dec 2019 22:46 UTC
Re: Directory listings, continued Lassi Kortela 10 Dec 2019 22:48 UTC
Re: Directory listings, continued hga@xxxxxx 10 Dec 2019 23:44 UTC
Re: Directory listings, continued John Cowan 11 Dec 2019 00:08 UTC
Re: Directory listings, continued hga@xxxxxx 11 Dec 2019 02:00 UTC
Re: Directory listings, continued Shiro Kawai 11 Dec 2019 03:16 UTC
Re: Directory listings, continued Lassi Kortela 11 Dec 2019 10:58 UTC
Re: Directory listings, continued hga@xxxxxx 11 Dec 2019 14:13 UTC
Re: Directory listings, continued John Cowan 11 Dec 2019 15:58 UTC
Generators and object ports Lassi Kortela 11 Dec 2019 17:56 UTC
Re: Generators and object ports John Cowan 11 Dec 2019 19:29 UTC
Re: Directory listings, continued Shiro Kawai 11 Dec 2019 18:50 UTC
DIrectory handles versus directory-listing handles (and procedure naming) Lassi Kortela 11 Dec 2019 13:03 UTC
Re: DIrectory handles versus directory-listing handles (and procedure naming) Lassi Kortela 11 Dec 2019 13:07 UTC
Re: DIrectory handles versus directory-listing handles (and procedure naming) hga@xxxxxx 11 Dec 2019 13:58 UTC
Re: DIrectory handles versus directory-listing handles (and procedure naming) Lassi Kortela 11 Dec 2019 14:22 UTC
Re: DIrectory handles versus directory-listing handles (and procedure naming) John Cowan 11 Dec 2019 15:10 UTC
Re: DIrectory handles versus directory-listing handles (and procedure naming) hga@xxxxxx 11 Dec 2019 15:24 UTC

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.