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

Re: DIrectory handles versus directory-listing handles (and procedure naming) hga@xxxxxx 11 Dec 2019 13:58 UTC

Only commenting on the name choice:

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Wednesday, December 11, 2019 7:03 AM
>
> > 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.

The idea I have about their current names is that they're simple Scheme
style full versions of the POSIX call, opendir -> open-directory.

Sometimes we do that, sometimes I think we're compelled to ignore that
scheme, like utimensat -> set-file-timespecs, sometimes we do the same
with a less compelling case, like chmod -> set-file-mode.

chmod is one of the Old Ones, when names were artificially limited in
length, so we also do open -> open-file.  We *don't* currently support
handing open-file the O_DIRECTORY enforcement flag (returns an error if
you're not opening a directory), and I'm not at all sure this SRFI
should support that, we'd have to do things like expose the dirent
struct, which we current hide behind read-directory.

Although that struct is boring, just the filename and "File serial
number", i.e. inode.  We support reporting the inode with file-info,
but don't otherwise provide anything about them.

- Harold