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:27 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:27 UTC

On Thu, Dec 12, 2019 at 8:21 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> >> Then again, if the pathname exceeds PATH_MAX you wouldn't be able to operate on it
> >> anyway.
> >
> > Not really. As an example, you can open the first half of the path
> > (still shorter than PATH_MAX) with open(), then pass the second half
> > to openat().
> That's similar to what Gambit is doing. But the OS won't let your
> process allocate any more file descriptors, then you can't open() any of
> the parent directories. The per-process limit can be set with `ulimit
> -n` can be quite strict in some environments.

But we don't need to keep the directory fd open after you have done
fooat(). Keeping a fixed number of open fds would be an optimization
to avoid doubling the number of system calls.

I could see a bad person really pushing it to the limit. But then he
or she already has a way to open() nearly unlimited fds. The fixed
number of cached fds only makes it happen a little bit sooner.
--
Duy