to facilitate future extensions (see the "Extensibility" section of the
.B NOTES
for more detail on how extensions are handled.)
-
+.\"
.SS The open_how structure
The following structure indicates how
.I pathname
The caller should explicitly specify
.B RESOLVE_NO_MAGICLINKS
to ensure that magic links are not resolved.
-
.TP
.B RESOLVE_IN_ROOT
Treat
.IR resolve .
.RE
.RE
-
.SH RETURN VALUE
On success, a new file descriptor is returned.
On error, -1 is returned, and
.I errno
is set appropriately.
-
.SH ERRORS
The set of errors returned by
.BR openat2 ()
contains either
.BR RESOLVE_IN_ROOT " or " RESOLVE_BENEATH ,
and an escape from the root during path resolution was detected.
-
.TP
.B EXDEV
.I resolve
contains
.BR RESOLVE_NO_XDEV ,
and a path component attempted to cross a mount point.
-
.TP
.B ELOOP
.I resolve
contains
.BR RESOLVE_NO_MAGICLINKS ,
and one of the path components was a magic link.
-
.SH VERSIONS
.BR openat2 ()
first appeared in Linux 5.6.
-
.SH CONFORMING TO
This system call is Linux-specific.
.B RESOLVE_BENEATH
were modelled after FreeBSD's
.BR O_BENEATH .
-
.SH NOTES
Glibc does not provide a wrapper for this system call; call it using
.BR syscall (2).
-
+.\"
.SS Extensibility
In order to allow for
.I struct open_how
.I ksize
be the size of the structure which the kernel supports, then there are only
three cases to consider:
-
.RS
.IP * 3
If
with a structure which has every byte non-zero (to find the largest value
which doesn't produce an error of
.BR E2BIG .)
-
.SH SEE ALSO
.BR openat (2),
.BR path_resolution (7),