open_by_handle_at (2) - Linux Manuals
open_by_handle_at: obtain handle
NAME
name_to_handle_at, open_by_handle_at - obtain handle for a pathname and open file via a handle
SYNOPSIS
#define _GNU_SOURCE /* See feature_test_macros(7) */ #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> int name_to_handle_at(int dirfd, const char *pathname, struct file_handle *handle, int *mount_id, int flags); int open_by_handle_at(int mount_fd, struct file_handle *handle, int flags);
DESCRIPTION
The name_to_handle_at() and open_by_handle_at() system calls split the functionality of openat(2) into two parts: name_to_handle_at() returns an opaque handle that corresponds to a specified file; open_by_handle_at() opens the file corresponding to a handle returned by a previous call to name_to_handle_at() and returns an open file descriptor.name_to_handle_at()
The name_to_handle_at() system call returns a file handle and a mount ID corresponding to the file specified by the dirfd and pathname arguments. The file handle is returned via the argument handle, which is a pointer to a structure of the following form:
struct file_handle {
It is the caller's responsibility to allocate the structure
with a size large enough to hold the handle returned in
f_handle.
Before the call, the
handle_bytes
field should be initialized to contain the allocated size for
f_handle.
(The constant
MAX_HANDLE_SZ,
defined in
<fcntl.h>,
specifies the maximum expected size for a file handle.
It is not a
guaranteed upper limit as future filesystems may require more space.)
Upon successful return, the
handle_bytes
field is updated to contain the number of bytes actually written to
f_handle.
The caller can discover the required size for the
file_handle
structure by making a call in which
handle->handle_bytes
is zero;
in this case, the call fails with the error
EOVERFLOW
and
handle->handle_bytes
is set to indicate the required size;
the caller can then use this information to allocate a structure
of the correct size (see EXAMPLES below).
Some care is needed here as
EOVERFLOW
can also indicate that no file handle is available for this particular
name in a filesystem which does normally support file-handle lookup.
This case can be detected when the
EOVERFLOW
error is returned without
handle_bytes
being increased.
Other than the use of the
handle_bytes
field, the caller should treat the
file_handle
structure as an opaque data type: the
handle_type
and
f_handle
fields are needed only by a subsequent call to
open_by_handle_at().
The
flags
argument is a bit mask constructed by ORing together zero or more of
AT_EMPTY_PATH
and
AT_SYMLINK_FOLLOW,
described below.
Together, the
pathname
and
dirfd
arguments identify the file for which a handle is to be obtained.
There are four distinct cases:
The
mount_id
argument returns an identifier for the filesystem
mount that corresponds to
pathname.
This corresponds to the first field in one of the records in
/proc/self/mountinfo.
Opening the pathname in the fifth field of that record yields a file
descriptor for the mount point;
that file descriptor can be used in a subsequent call to
open_by_handle_at().
mount_id
is returned both for a successful call and for a call that results
in the error
EOVERFLOW.
By default,
name_to_handle_at()
does not dereference
pathname
if it is a symbolic link, and thus returns a handle for the link itself.
If
AT_SYMLINK_FOLLOW
is specified in
flags,
pathname
is dereferenced if it is a symbolic link
(so that the call returns a handle for the file referred to by the link).
name_to_handle_at()
does not trigger a mount when the final component of the pathname is an
automount point.
When a filesystem supports both file handles and
automount points, a
name_to_handle_at()
call on an automount point will return with error
EOVERFLOW
without having increased
handle_bytes.
This can happen since Linux 4.13
with NFS when accessing a directory
which is on a separate filesystem on the server.
In this case, the automount can be triggered by adding a "/" to the end
of the pathname.
The
mount_fd
argument is a file descriptor for any object (file, directory, etc.)
in the mounted filesystem with respect to which
handle
should be interpreted.
The special value
AT_FDCWD
can be specified, meaning the current working directory of the caller.
The
flags
argument
is as for
open(2).
If
handle
refers to a symbolic link, the caller must specify the
O_PATH
flag, and the symbolic link is not dereferenced; the
O_NOFOLLOW
flag, if specified, is ignored.
The caller must have the
CAP_DAC_READ_SEARCH
capability to invoke
open_by_handle_at().
In the event of an error, both system calls return -1 and set
errno
to indicate the cause of the error.
name_to_handle_at()
can fail with the following errors:
open_by_handle_at()
can fail with the following errors:
FreeBSD has a broadly similar pair of system calls in the form of
getfh()
and
openfh().
Some filesystem don't support the translation of pathnames to
file handles, for example,
/proc,
/sys,
and various network filesystems.
A file handle may become invalid ("stale") if a file is deleted,
or for other filesystem-specific reasons.
Invalid handles are notified by an
ESTALE
error from
open_by_handle_at().
These system calls are designed for use by user-space file servers.
For example, a user-space NFS server might generate a file handle
and pass it to an NFS client.
Later, when the client wants to open the file,
it could pass the handle back to the server.
This sort of functionality allows a user-space file server to operate in
a stateless fashion with respect to the files it serves.
If
pathname
refers to a symbolic link and
flags
does not specify
AT_SYMLINK_FOLLOW,
then
name_to_handle_at()
returns a handle for the link (rather than the file to which it refers).
The process receiving the handle can later perform operations
on the symbolic link by converting the handle to a file descriptor using
open_by_handle_at()
with the
O_PATH
flag, and then passing the file descriptor as the
dirfd
argument in system calls such as
readlinkat(2)
and
fchownat(2).
For example, one can use the device name in the fifth field of the
mountinfo
record to search for the corresponding device UUID via the symbolic links in
/dev/disks/by-uuid.
(A more comfortable way of obtaining the UUID is to use the
libblkid(3)
library.)
That process can then be reversed,
using the UUID to look up the device name,
and then obtaining the corresponding mount point,
in order to produce the
mount_fd
argument used by
open_by_handle_at().
The second program
(t_open_by_handle_at.c)
reads a mount ID and file handle from standard input.
The program then employs
open_by_handle_at()
to open the file using that handle.
If an optional command-line argument is supplied, then the
mount_fd
argument for
open_by_handle_at()
is obtained by opening the directory named in that argument.
Otherwise,
mount_fd
is obtained by scanning
/proc/self/mountinfo
to find a record whose mount ID matches the mount ID
read from standard input,
and the mount directory specified in that record is opened.
(These programs do not deal with the fact that mount IDs are not persistent.)
The following shell session demonstrates the use of these two programs:
$ echo 'Can you please think about it?' > cecilia.txt
$ ./t_name_to_handle_at cecilia.txt > fh
$ ./t_open_by_handle_at < fh
open_by_handle_at: Operation not permitted
$ sudo ./t_open_by_handle_at < fh # Need CAP_SYS_ADMIN
Read 31 bytes
$ rm cecilia.txt
Now we delete and (quickly) re-create the file so that
it has the same content and (by chance) the same inode.
Nevertheless,
open_by_handle_at()
recognizes that the original file referred to by the file handle
no longer exists.
$ stat --printf="%i\n" cecilia.txt # Display inode number
4072121
$ rm cecilia.txt
$ echo 'Can you please think about it?' > cecilia.txt
$ stat --printf="%i\n" cecilia.txt # Check inode number
4072121
$ sudo ./t_open_by_handle_at < fh
open_by_handle_at: Stale NFS file handle
#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \
int
main(int argc, char *argv[])
{
open_by_handle_at()
The
open_by_handle_at()
system call opens the file referred to by
handle,
a file handle returned by a previous call to
name_to_handle_at().
RETURN VALUE
On success,
name_to_handle_at()
returns 0,
and
open_by_handle_at()
returns a file descriptor (a nonnegative integer).
ERRORS
name_to_handle_at()
and
open_by_handle_at()
can fail for the same errors as
openat(2).
In addition, they can fail with the errors noted below.
VERSIONS
These system calls first appeared in Linux 2.6.39.
Library support is provided in glibc since version 2.14.
CONFORMING TO
These system calls are nonstandard Linux extensions.
NOTES
A file handle can be generated in one process using
name_to_handle_at()
and later used in a different process that calls
open_by_handle_at().
Obtaining a persistent filesystem ID
The mount IDs in
/proc/self/mountinfo
can be reused as filesystems are unmounted and mounted.
Therefore, the mount ID returned by
name_to_handle_at()
(in
*mount_id)
should not be treated as a persistent identifier
for the corresponding mounted filesystem.
However, an application can use the information in the
mountinfo
record that corresponds to the mount ID
to derive a persistent identifier.
EXAMPLES
The two programs below demonstrate the use of
name_to_handle_at()
and
open_by_handle_at().
The first program
(t_name_to_handle_at.c)
uses
name_to_handle_at()
to obtain the file handle and mount ID
for the file specified in its command-line argument;
the handle and mount ID are written to standard output.
Program source: t_name_to_handle_at.c
#define _GNU_SOURCE
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>