LLFIO
v2.00
|
A handle to an inode which redirects to a different path. More...
#include "symlink_handle.hpp"
Classes | |
struct | buffers_type |
struct | const_buffers_type |
struct | io_request |
The i/o request type used by this handle. More... | |
struct | io_request< buffers_type, ____ > |
Specialisation for reading symlinks. More... | |
struct | io_request< const_buffers_type, ____ > |
Specialisation for writing symlinks. More... | |
Public Types | |
enum class | symlink_type { none , symbolic , win_wsl , win_junction } |
The type of symbolic link this is. More... | |
using | path_type = handle::path_type |
using | extent_type = handle::extent_type |
using | size_type = handle::size_type |
using | mode = handle::mode |
using | creation = handle::creation |
using | caching = handle::caching |
using | flag = handle::flag |
using | dev_t = fs_handle::dev_t |
using | ino_t = fs_handle::ino_t |
using | path_view_type = fs_handle::path_view_type |
using | buffer_type = path_view |
The buffer type used by this handle, which is a path_view | |
using | const_buffer_type = path_view |
The const buffer type used by this handle, which is a path_view | |
using | unique_id_type = QUICKCPPLIB_NAMESPACE::integers128::uint128 |
The unique identifier type used by this handle. | |
using | unique_id_type_hasher = QUICKCPPLIB_NAMESPACE::integers128::uint128_hasher |
A hasher for the unique identifier type used by this handle. | |
Public Member Functions | |
symlink_handle () | |
Default constructor. | |
symlink_handle (native_handle_type h, dev_t devid, ino_t inode, flag flags=flag::none) | |
Construct a handle from a supplied native handle. | |
symlink_handle (handle &&o) noexcept | |
Explicit conversion from handle permitted. | |
symlink_handle (symlink_handle &&)=default | |
Move construction permitted. | |
symlink_handle (const symlink_handle &)=delete | |
No copy construction (use clone() ) | |
symlink_handle & | operator= (symlink_handle &&o) noexcept |
Move assignment permitted. | |
symlink_handle & | operator= (const symlink_handle &)=delete |
No copy assignment. | |
void | swap (symlink_handle &o) noexcept |
Swap with another instance. | |
virtual result< void > | close () noexcept override |
Immediately close the native handle type managed by this handle. | |
virtual result< symlink_handle > | reopen (mode mode_=mode::unchanged, deadline d=std::chrono::seconds(30)) const noexcept |
template<class... Args> | |
bool | try_reopen (Args &&... args) noexcept |
template<class... Args, class Rep , class Period > | |
bool | try_reopen_for (Args &&... args, const std::chrono::duration< Rep, Period > &duration) noexcept |
template<class... Args, class Clock , class Duration > | |
bool | try_reopen_until (Args &&... args, const std::chrono::time_point< Clock, Duration > &timeout) noexcept |
virtual result< path_type > | current_path () const noexcept override |
virtual result< void > | relink (const path_handle &base, path_view_type path, bool atomic_replace=true, deadline d=std::chrono::seconds(30)) noexcept override |
Relinks the current path of this open handle to the new path specified. If atomic_replace is true, the relink atomically and silently replaces any item at the new path specified. This operation is both atomic and matching POSIX behaviour even on Microsoft Windows where no Win32 API can match POSIX semantics. More... | |
virtual result< void > | unlink (deadline d=std::chrono::seconds(30)) noexcept override |
Unlinks the current path of this open handle, causing its entry to immediately disappear from the filing system. More... | |
virtual result< buffers_type > | read (io_request< buffers_type > req={}) noexcept |
virtual result< const_buffers_type > | write (io_request< const_buffers_type > req, deadline d=deadline()) noexcept |
flag | flags () const noexcept |
The flags this handle was opened with. | |
QUICKCPPLIB_BITFIELD_BEGIN_T (flag, uint16_t) | |
Bitwise flags which can be specified. More... | |
void | swap (handle &o) noexcept |
Swap with another instance. | |
result< handle > | clone () const noexcept |
virtual native_handle_type | release () noexcept |
Release the native handle type managed by this handle. | |
bool | is_valid () const noexcept |
True if the handle is valid (and usually open) | |
bool | is_readable () const noexcept |
True if the handle is readable. | |
bool | is_writable () const noexcept |
True if the handle is writable. | |
bool | is_append_only () const noexcept |
True if the handle is append only. | |
virtual result< void > | set_append_only (bool enable) noexcept |
EXTENSION: Changes whether this handle is append only or not. More... | |
bool | is_multiplexable () const noexcept |
True if multiplexable. | |
bool | is_nonblocking () const noexcept |
True if nonblocking. | |
bool | is_seekable () const noexcept |
True if seekable. | |
bool | requires_aligned_io () const noexcept |
True if requires aligned i/o. | |
bool | is_kernel_handle () const noexcept |
True if native_handle() is a valid kernel handle. | |
bool | is_regular () const noexcept |
True if a regular file or device. | |
bool | is_directory () const noexcept |
True if a directory. | |
bool | is_symlink () const noexcept |
True if a symlink. | |
bool | is_pipe () const noexcept |
True if a pipe. | |
bool | is_socket () const noexcept |
True if a socket. | |
bool | is_multiplexer () const noexcept |
True if a multiplexer like BSD kqueues, Linux epoll or Windows IOCP. | |
bool | is_process () const noexcept |
True if a process. | |
bool | is_section () const noexcept |
True if a memory section. | |
bool | is_allocation () const noexcept |
True if a memory allocation. | |
bool | is_path () const noexcept |
True if a path or a directory. | |
bool | is_tls_socket () const noexcept |
True if a TLS socket. | |
bool | is_http_socket () const noexcept |
True if a HTTP socket. | |
caching | kernel_caching () const noexcept |
Kernel cache strategy used by this handle. | |
bool | are_reads_from_cache () const noexcept |
True if the handle uses the kernel page cache for reads. | |
bool | are_writes_durable () const noexcept |
True if writes are safely on storage on completion. | |
bool | are_safety_barriers_issued () const noexcept |
True if issuing safety fsyncs is on. | |
native_handle_type | native_handle () const noexcept |
The native handle used by this handle. | |
dev_t | st_dev () const noexcept |
Unless flag::disable_safety_unlinks is set, the device id of the file when opened. | |
ino_t | st_ino () const noexcept |
Unless flag::disable_safety_unlinks is set, the inode of the file when opened. When combined with st_dev(), forms a unique identifer on this system. | |
unique_id_type | unique_id () const noexcept |
A unique identifier for this handle across the entire system. Can be used in hash tables etc. | |
virtual result< path_handle > | parent_path_handle (deadline d=std::chrono::seconds(30)) const noexcept |
Obtain a handle to the path currently containing this handle's file entry. More... | |
template<class... Args> | |
bool | try_parent_path_handle (Args &&... args) noexcept |
template<class... Args, class Rep , class Period > | |
bool | try_parent_path_handle_for (Args &&... args, const std::chrono::duration< Rep, Period > &duration) noexcept |
template<class... Args, class Clock , class Duration > | |
bool | try_parent_path_handle_until (Args &&... args, const std::chrono::time_point< Clock, Duration > &timeout) noexcept |
template<class... Args> | |
bool | try_relink (Args &&... args) noexcept |
template<class... Args, class Rep , class Period > | |
bool | try_relink_for (Args &&... args, const std::chrono::duration< Rep, Period > &duration) noexcept |
template<class... Args, class Clock , class Duration > | |
bool | try_relink_until (Args &&... args, const std::chrono::time_point< Clock, Duration > &timeout) noexcept |
virtual result< void > | link (const path_handle &base, path_view_type path, deadline d=std::chrono::seconds(30)) noexcept |
Links the inode referred to by this open handle to the path specified. The current path of this open handle is not changed, unless it has no current path due to being unlinked. More... | |
template<class... Args> | |
bool | try_link (Args &&... args) noexcept |
template<class... Args, class Rep , class Period > | |
bool | try_link_for (Args &&... args, const std::chrono::duration< Rep, Period > &duration) noexcept |
template<class... Args, class Clock , class Duration > | |
bool | try_link_until (Args &&... args, const std::chrono::time_point< Clock, Duration > &timeout) noexcept |
template<class... Args> | |
bool | try_unlink (Args &&... args) noexcept |
template<class... Args, class Rep , class Period > | |
bool | try_unlink_for (Args &&... args, const std::chrono::duration< Rep, Period > &duration) noexcept |
template<class... Args, class Clock , class Duration > | |
bool | try_unlink_until (Args &&... args, const std::chrono::time_point< Clock, Duration > &timeout) noexcept |
virtual result< span< path_view_component > > | list_extended_attributes (span< byte > tofill) const noexcept |
Fill the supplied buffer with the names of all extended attributes set on this file or directory, returning a span of path view components. More... | |
virtual result< span< byte > > | get_extended_attribute (span< byte > tofill, path_view_component name) const noexcept |
Retrieve the value of an extended attribute set on this file or directory. More... | |
virtual result< void > | set_extended_attribute (path_view_component name, span< const byte > value) noexcept |
Sets the value of an extended attribute on this file or directory. More... | |
virtual result< void > | remove_extended_attribute (path_view_component) noexcept |
Removes the extended attribute set on this file or directory. More... | |
result< size_t > | copy_extended_attributes (const fs_handle &src, bool replace_all_local_attributes=false) noexcept |
Copies the extended attributes from one entity to another, optionally replacing all the extended attributes on the destination. More... | |
Static Public Member Functions | |
static result< symlink_handle > | symlink (const path_handle &base, path_view_type path, mode _mode=mode::read, creation _creation=creation::open_existing, flag flags=flag::none) noexcept |
static result< symlink_handle > | uniquely_named_symlink (const path_handle &dirpath, mode _mode=mode::write, flag flags=flag::none) noexcept |
Protected Member Functions | |
result< void > | _fetch_inode () const noexcept |
Fill in _devid and _inode from the handle via fstat() | |
Protected Attributes | |
union { | |
native_handle_type _v | |
struct { | |
intptr_t _padding0_ | |
uint32_t _padding1_ | |
flag flags | |
uint16_t _padding2_ | |
} _ | |
}; | |
dev_t | _devid {0} |
ino_t | _inode {0} |
A handle to an inode which redirects to a different path.
Microsoft Windows and Linux provide the ability to open the contents of a symbolic link directly, for those platforms this handle works exactly like any ordinary handle. For other POSIX platforms without proprietary extensions, it is not possible to get a valid file descriptor to the contents of a symlink, and in this situation the native handle returned will be -1
and the preprocessor macro LLFIO_SYMLINK_HANDLE_IS_FAKED
will be non-zero.
If LLFIO_SYMLINK_HANDLE_IS_FAKED
is on, the handle is race free up to the containing directory only. If a third party relocates the symbolic link into a different directory, and race free checking is enabled, this class will simply refuse to work with errc::no_such_file_or_directory
as it no longer has any way of finding the symbolic link. You should take care that this does not become a denial of service attack.
On Microsoft Windows, there are many kinds of symbolic link: this implementation supports directory junctions, and NTFS symbolic links. Reads of any others will return an error code comparing equal to errc::protocol_not_supported
. One should note that modifying symbolic links was not historically permitted by users with ordinary permissions on Microsoft Windows, however recent versions of Windows 10 do support symbolic links for ordinary users. All versions of Windows support directory symbolic links (junctions), these work for all users in any configuration.
(Note that to create a directory junction on Windows, first create a directory, open that empty directory for modification using symlink_handle, then write using symlink_type::win_junction
)
|
strong |
|
inlinenoexceptinherited |
Clone this handle (copy constructor is disabled to avoid accidental copying)
|
inlinenoexceptinherited |
Copies the extended attributes from one entity to another, optionally replacing all the extended attributes on the destination.
This convenience function is implemented using the APIs above, and therefore is racy with respect to concurrent users. If you specifiy an invalid source with replace_all_local_attributes = true
, then this is a convenient way to remove all extended attributes on the local inode.
|
inlineoverridevirtualnoexcept |
Returns the current path of the open handle as said by the operating system. Note that you are NOT guaranteed that any path refreshed bears any resemblance to the original, some operating systems will return some different path which still reaches the same inode via some other route e.g. hardlinks, dereferenced symbolic links, etc. Windows and Linux correctly track changes to the specific path the handle was opened with, not getting confused by other hard links. MacOS nearly gets it right, but under some circumstances e.g. renaming may switch to a different hard link's path which is almost certainly a bug.
If LLFIO was not able to determine the current path for this open handle e.g. the inode has been unlinked, it returns an empty path. Be aware that FreeBSD can return an empty (deleted) path for file inodes no longer cached by the kernel path cache, LLFIO cannot detect the difference. FreeBSD will also return any path leading to the inode if it is hard linked. FreeBSD does implement path retrieval for directory inodes correctly however, and see algorithm::cached_parent_handle_adapter<T>
for a handle adapter which makes use of that.
On Linux if /proc
is not mounted, this call fails with an error. All APIs in LLFIO which require the use of current_path()
can be told to not use it e.g. flag::disable_safety_unlinks
. It is up to you to detect if current_path()
is not working, and to change how you call LLFIO appropriately.
On Windows, you will almost certainly get back a path of the form \!!\Device\HarddiskVolume10\Users\ned\...
. See path_view
for what all the path prefix sequences mean, but to summarise the \!!\
prefix is LLFIO-only and will not be accepted by other Windows APIs. Pass LLFIO derived paths through the function to_win32_path()
to Win32-ise them. This function is also available on Linux where it does nothing, so you can use it in portable code.
path_handle
to fix a base location on the file system and work from that anchor instead!algorithm::cached_parent_handle_adapter<T>
which overrides this with an implementation based on retrieving the current path of a cached handle to the parent directory. On platforms with instability or failure to retrieve the correct current path for regular files, the cached parent handle adapter works around the problem by taking advantage of directory inodes not having the same instability problems on any platform. Reimplemented from llfio_v2_xxx::handle.
|
inlinevirtualnoexceptinherited |
Retrieve the value of an extended attribute set on this file or directory.
|
inlinevirtualnoexceptinherited |
Links the inode referred to by this open handle to the path specified. The current path of this open handle is not changed, unless it has no current path due to being unlinked.
flag::disable_safety_unlinks
is set, this implementation opens a path_handle
to the source containing directory first, then checks before linking that the item about to be hard linked has the same inode as the open file handle. It will retry this matching until success until the deadline given. This should prevent most unmalicious accidental loss of data.base | Base for any relative path. |
path | The relative or absolute new path to hard link to. |
d | The deadline by which the matching of the containing directory to the open handle's inode must succeed, else errc::timed_out will be returned. |
current_path()
via parent_path_handle()
and thus is both expensive and calls malloc many times.
|
inlinevirtualnoexceptinherited |
Fill the supplied buffer with the names of all extended attributes set on this file or directory, returning a span of path view components.
Note that this routine is a very thin wrap of listxattr()
on POSIX and NtQueryInformationFile()
on Windows. If the supplied buffer is too small, the syscall typically returns failure rather than do a partial fill. Most implementations do not support more than 64Kb of extended attribute information per inode so maybe 70Kb is a safe default (to account for the return value storage), however properly written code will detect the buffer being too small and will auto-expand it until success.
|
inlinevirtualnoexceptinherited |
Obtain a handle to the path currently containing this handle's file entry.
flag::disable_safety_unlinks
is set, this implementation opens a path_handle
to the source containing directory, then checks if the file entry within has the same inode as the open file handle. It will retry this matching until success until the deadline given.algorithm::cached_parent_handle_adapter<T>
which overrides this with a zero cost implementation, thus making unlinking and relinking very considerably quicker.
|
inlineinherited |
Bitwise flags which can be specified.
< No flags
Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed to by path()
upon the call of close()
if and only if the inode matches. On Windows, if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous editions of Windows, the file entry does not disappears but becomes unavailable for anyone else to open with an errc::resource_unavailable_try_again
error return. Because this is confusing, unless the win_disable_unlink_emulation
flag is also specified, this POSIX behaviour is somewhat emulated by LLFIO on older Windows by renaming the file to a random name on close()
causing it to appear to have been unlinked immediately.
Some kernel caching modes have unhelpfully inconsistent behaviours in getting your data onto storage, so by default unless this flag is specified LLFIO adds extra fsyncs to the following operations for the caching modes specified below: truncation of file length either explicitly or during file open. closing of the handle either explicitly or in the destructor.
Additionally on Linux only to prevent loss of file metadata: On the parent directory whenever a file might have been created. On the parent directory on file close.
This only occurs for these kernel caching modes: caching::none caching::reads caching::reads_and_metadata caching::safety_barriers
file_handle::unlink()
could accidentally delete the wrong file if someone has renamed the open file handle since the time it was opened. To prevent this occuring, where the OS doesn't provide race free unlink-by-open-handle we compare the inode of the path we are about to unlink with that of the open handle before unlinking.
Ask the OS to disable prefetching of data. This can improve random i/o performance.
Ask the OS to maximise prefetching of data, possibly prefetching the entire file into kernel cache. This can improve sequential i/o performance.
< See the documentation for unlink_on_first_close
Microsoft Windows NTFS, having been created in the late 1980s, did not originally implement extents-based storage and thus could only represent sparse files via efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000), a proper extents-based on-storage representation was added, thus allowing only 64Kb extent chunks written to be stored irrespective of whatever the maximum file extent was set to.
For various historical reasons, extents-based storage is disabled by default in newly created files on NTFS, unlike in almost every other major filing system. You have to explicitly "opt in" to extents-based storage.
As extents-based storage is nearly cost free on NTFS, LLFIO by default opts in to extents-based storage for any empty file it creates. If you don't want this, you can specify this flag to prevent that happening.
Filesystems tend to be embarrassingly parallel for operations performed to different inodes. Where LLFIO performs i/o to multiple inodes at a time, it will use OpenMP or the Parallelism or Concurrency standard library extensions to usually complete the operation in constant rather than linear time. If you don't want this default, you can disable default using this flag.
Microsoft Windows NTFS has the option, when creating a directory, to set whether leafname lookup will be case sensitive. This is the only way of getting exact POSIX semantics on Windows without resorting to editing the system registry, however it also affects all code doing lookups within that directory, so we must default it to off.
Create the handle in a way where i/o upon it can be multiplexed with other i/o on the same initiating thread of execution i.e. you can perform more than one read concurrently, without using threads. The blocking operations .read()
and .write()
may have to use a less efficient, but cancellable, blocking implementation for handles created in this way. On Microsoft Windows, this creates handles with OVERLAPPED
semantics. On POSIX, this creates handles with nonblocking semantics for non-file handles such as pipes and sockets, however for file, directory and symlink handles it does not set nonblocking, as it is non-portable.
< Using insane POSIX byte range locks
< This is an inode created with no representation on the filing system
|
inlinevirtualnoexcept |
Read the contents of the symbolic link.
If supplying your own kernelbuffer
, be aware that the length of the contents of the symbolic link may change at any time. You should therefore retry reading the symbolic link, expanding your kernelbuffer
each time, until a successful read occurs.
req | A buffer to fill with the contents of the symbolic link. |
|
inlineoverridevirtualnoexcept |
Relinks the current path of this open handle to the new path specified. If atomic_replace
is true, the relink atomically and silently replaces any item at the new path specified. This operation is both atomic and matching POSIX behaviour even on Microsoft Windows where no Win32 API can match POSIX semantics.
Note that if atomic_replace
is false, the operation may be implemented as creating a hard link to the destination (which fails if the destination exists), opening a new file descriptor to the destination, closing the existing file descriptor, replacing the existing file descriptor with the new one (this is to ensure path tracking continues to work), then unlinking the previous link. Thus native_handle()
's value may change. This is not the case on Microsoft Windows nor Linux, both of which provide syscalls capable of refusing to rename if the destination exists.
If the handle refers to a pipe, on Microsoft Windows the base path handle is ignored as there is a single global named pipe namespace. Unless the path fragment begins with \
, the string \??\
is prefixed to the name before passing it to the NT kernel API which performs the rename. This is because \\.\
in Win32 maps onto \??\
in the NT kernel.
flag::disable_safety_unlinks
is set, this implementation opens a path_handle
to the source containing directory first, then checks before relinking that the item about to be relinked has the same inode as the open file handle. It will retry this matching until success until the deadline given. This should prevent most unmalicious accidental loss of data.base | Base for any relative path. |
path | The relative or absolute new path to relink to. |
atomic_replace | Atomically replace the destination if a file entry already is present there. Choosing false for this will fail if a file entry is already present at the destination, and may not be an atomic operation on some platforms (i.e. both the old and new names may be linked to the same inode for a very short period of time). Windows and recent Linuxes are always atomic. |
d | The deadline by which the matching of the containing directory to the open handle's inode must succeed, else errc::timed_out will be returned. |
current_path()
via parent_path_handle()
and thus is both expensive and calls malloc many times. Reimplemented from llfio_v2_xxx::fs_handle.
|
inlinevirtualnoexceptinherited |
Removes the extended attribute set on this file or directory.
|
inlinevirtualnoexcept |
Reopen this handle (copy constructor is disabled to avoid accidental copying), optionally race free reopening the handle with different access or caching.
Microsoft Windows provides a syscall for cloning an existing handle but with new access. On POSIX, we must loop calling current_path()
, trying to open the path returned and making sure it is the same inode.
|
inlinevirtualnoexceptinherited |
EXTENSION: Changes whether this handle is append only or not.
Reimplemented in llfio_v2_xxx::process_handle.
|
inlinevirtualnoexceptinherited |
Sets the value of an extended attribute on this file or directory.
To prevent collision in a globally visible resource, there is a convention whereby you ought to namespace the names of your values as namespace.attribute
e.g. appname.setting
to prevent unintentional collision with other programs. Obviously, do choose a unique appname
if there is any chance another program might use the same namespace name.
On POSIX, there are additional namespacing requirements: before your value name, you need to prefix one of user
or system
, so the actual name you might set would be user.appname.propname
. Windows does not have the user
/system
prefix requirement, but it does no harm to do the exact same on Windows as on POSIX.
The host OS and target filing system choose the limits on value size, and will fail accordingly. Some impose a maximum of 64Kb for all names and values per inode, others have a 4Kb maximum value size, there are lots of combinations. You are probably safest not setting many names, and keep the values short.
This API is implemented as file alternate data streams, rather than the Extended Attributes API as accessed via NtSetEaFile()
and NtQueryEaFile()
(which actually modify the file alternate data stream $EA
in any case).
The reason why is that NtSetEaFile()
can only append new records to EA storage. It cannot deallocate any existing EA records, if you try to do so you will get STATUS_EA_CORRUPT_ERROR
. You can append setting the same name to a different value, which can include a null value which then appears as if the name is no longer there. But there is a cap of 64kB for the EA record, and once it is consumed, it is gone forever for that inode.
Obviously that doesn't map at all well onto POSIX extended attributes, where you can set the value of an attribute as frequently as you like. The closest equivalent on Windows is therefore file alternate data streams, even though the attribute's value is then worked with as a whole proper file with all the attendant performance consequences.
As a result, name
must be a valid filename and not contain any characters not permitted in a filename. We use the NT API here, so the character restrictions are far fewer than for the Win32 API e.g. single character names do NOT cause misoperation like on Win32.
|
inlinestaticnoexcept |
Create a symlink handle opening access to a symbolic link.
For obvious reasons, one cannot append to a symbolic link, nor create with truncate. In this situation a failure comparing equal to errc::function_not_supported
shall be returned.
|
inlinestaticnoexcept |
Create a symlink handle creating a uniquely named symlink on a path. The symlink is opened exclusively with creation::only_if_not_exist
so it will never collide with nor overwrite any existing symlink.
|
inlineoverridevirtualnoexcept |
Unlinks the current path of this open handle, causing its entry to immediately disappear from the filing system.
On Windows before Windows 10 1709 unless flag::win_disable_unlink_emulation
is set, this behaviour is simulated by renaming the file to something random and setting its delete-on-last-close flag. Note that Windows may prevent the renaming of a file in use by another process, if so it will NOT be renamed. After the next handle to that file closes, it will become permanently unopenable by anyone else until the last handle is closed, whereupon the entry will be eventually removed by the operating system.
flag::disable_safety_unlinks
is set, this implementation opens a path_handle
to the containing directory first, then checks that the item about to be unlinked has the same inode as the open file handle. It will retry this matching until success until the deadline given. This should prevent most unmalicious accidental loss of data.d | The deadline by which the matching of the containing directory to the open handle's inode must succeed, else errc::timed_out will be returned. |
current_path()
and thus is both expensive and calls malloc many times. On Windows, also calls current_path()
if flag::disable_safety_unlinks
is not set. Reimplemented from llfio_v2_xxx::fs_handle.
|
inlinevirtualnoexcept |
Write the contents of the symbolic link.
req | A buffer with which to replace the contents of the symbolic link. |
d | An optional deadline by which the i/o must complete, else it is cancelled. Ignored on Windows. |