Hello Paul, Bruno, On Tue, Oct 28, 2025 at 09:26:16PM -0700, Paul Eggert wrote: > Though I am starting to have my doubts about openat2 except as a base to > implement a nicer API. The openat2 API works only as an openat extension, > whereas what tar needs is an extension that also works for fstatat, > fchmodat, mkdirat, etc.
Thank you for the patch. One API was proposed in this blogpost: https://val.packett.cool/blog/use-openat/ , essentially: int open_beneath(int dirfd, const char *pathname, int flags, mode_t mode) { #ifdef __FreeBSD__ // TODO: validate flags/mode to match Linux behavior return openat(dirfd, pathname, flags | O_RESOLVE_BENEATH, mode); #elif defined(__linux__) struct open_how how = { .flags = flags, .mode = mode, .resolve = RESOLVE_BENEATH, }; return (int)syscall(SYS_openat2, dirfd, pathname, &how, sizeof(how)); #else ... #endif } To me it also seems it would make more sense to have just something like this instead of the complete openat2, especially if the API is not yet 100% fixed, as the other subthread indicates. Regarding the need of having something similar for fstatat, fchmodat, mkdirat, ... for tar, I suppose one could introduce similar fstat_beneath and so on, but wouldn't it be enough for tar to use openat2 (or open_beneath or whatever wrapper) and fstat / fchmod / mkdirat on the fd returned, instead of introducing more functions? (Sorry if there is a reason why openat2 does not work for fstatat etc. and I am missing it.) Best regards, Pavel
