получить дескриптор для имени пути и открыть файл через дескриптор (obtain handle for a pathname and open file via a handle)
Примечание (Note)
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().
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).
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.
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().
