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 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 Lassi Kortela 12 Dec 2019 12:59 UTC

>> 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.

Another reason is opening a directory at the start of a program and then
chdir() back into it later or access files relative to it. If that
directory is renamed from underneath the program, the program will still
keep working. This may be more important in security-sensitive programs
and in shells, etc.

> Gambit uses openat, unlinkat, etc (if available) to implement open-file, delete-file, etc that work regardless of the length of the path.

That's ingenious, but requires an extra file descriptor to open the
directory. In adverse circumstances, it may exceed the process limit on
open file descriptors and be unable to operate on the file. Then again,
if the pathname exceeds PATH_MAX you wouldn't be able to operate on it
anyway.