Email list hosting service & mailing list manager

Operations on file descriptors in addition to pathnames Lassi Kortela (11 Dec 2019 12:43 UTC)
Re: Operations on file descriptors in addition to pathnames Lassi Kortela (12 Dec 2019 12:59 UTC)
Re: Operations on file descriptors in addition to pathnames Lassi Kortela (12 Dec 2019 13:21 UTC)
Re: Operations on file descriptors in addition to pathnames Duy Nguyen (12 Dec 2019 13:13 UTC)
Re: Operations on file descriptors in addition to pathnames Lassi Kortela (12 Dec 2019 13:27 UTC)
Re: Operations on file descriptors in addition to pathnames Lassi Kortela (18 Dec 2019 20:52 UTC)

Re: Operations on file descriptors in addition to pathnames Duy Nguyen 12 Dec 2019 13:13 UTC

On Thu, Dec 12, 2019 at 7:36 PM Marc Feeley <xxxxxx@iro.umontreal.ca> wrote:
>
>
> > On Dec 12, 2019, at 2:46 AM, Duy Nguyen <xxxxxx@gmail.com> wrote:
> >
> > Are there good reasons to? I think these are mostly to prevent races
> > or maybe when path resolution becomes too expensive.
>
> Also needed to access files whose path exceeds PATH_MAX.  I’m not advodating anything concerning SRFI 170… just adding an important reason why openat exists.  Gambit uses openat, unlinkat, etc (if available) to implement open-file, delete-file, etc that work regardless of the length of the path.

Yeah I forgot about this. But I think we can do this behind the scene
without introducing new API in SRFI 170 (not that different from how
Gambit uses it, I guess). It's probably better that way from the user
perspective, because they only deal with pathnames.

The SRFI should probably make clear about PATH_MAX restriction if we
choose to support this. Maybe if "unlimited-path" feature is supported
by a Scheme implementation, then the user does not have to care about
PATH_MAX. Otherwise it's up to the user to handle ENAMETOOLONG
--
Duy