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