llfio_v2_xxx::path_handle Class Reference

A handle to somewhere originally identified by a path on the filing system. Typically used as the lightest weight handle to some location on the filing system which may unpredictably relocate over time. This handle is thus an anchor to a subset island of the filing system, free of any race conditions introduced by third party changes to any part of the path leading to that island. More...

#include "path_handle.hpp"

Inheritance diagram for llfio_v2_xxx::path_handle:

Public Types
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	path_view_type = path_view
	The path view type used by this handle.

Public Member Functions
constexpr	path_handle ()
	Default constructor.
constexpr	path_handle (native_handle_type h, caching caching=caching::all, flag flags=flag::none)
	Construct a handle from a supplied native handle.
constexpr	path_handle (handle &&o) noexcept
	Explicit conversion from handle permitted.
	path_handle (path_handle &&)=default
	Move construction permitted.
	path_handle (const path_handle &)=delete
	No copy construction (use clone())
path_handle &	operator= (path_handle &&o) noexcept
	Move assignment permitted.
path_handle &	operator= (const path_handle &)=delete
	No copy assignment.
void	swap (path_handle &o) noexcept
	Swap with another instance.
virtual result< void >	close () noexcept override
	Immediately close the native handle type managed by this handle.
result< path_handle >	clone () const noexcept
	QUICKCPPLIB_BITFIELD_BEGIN (flag)
	Bitwise flags which can be specified. More...
	QUICKCPPLIB_BITFIELD_END (flag)
void	swap (handle &o) noexcept
	Swap with another instance.
virtual result< path_type >	current_path () 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
bool	is_overlapped () const noexcept
	True if overlapped.
bool	is_seekable () const noexcept
	True if seekable.
bool	requires_aligned_io () const noexcept
	True if requires aligned i/o.
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_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.
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.
flag	flags () const noexcept
	The flags this handle was opened with.
native_handle_type	native_handle () const noexcept
	The native handle used by this handle.

Static Public Member Functions
static result< path_handle >	path (const path_handle &base, path_view_type path) noexcept
static result< path_handle >	path (path_view_type _path) noexcept

Protected Attributes
caching	_caching {caching::none}
flag	_flags {flag::none}
native_handle_type	_v

Friends
class	directory_handle

Detailed Description

A handle to somewhere originally identified by a path on the filing system. Typically used as the lightest weight handle to some location on the filing system which may unpredictably relocate over time. This handle is thus an anchor to a subset island of the filing system, free of any race conditions introduced by third party changes to any part of the path leading to that island.

Member Function Documentation

clone()

result<path_handle> llfio_v2_xxx::path_handle::clone ( ) const

inlinenoexcept

Clone this handle (copy constructor is disabled to avoid accidental copying).

  {
    auto *h = static_cast<const handle *>(this);
    OUTCOME_TRY(ret, h->clone());
    auto nativeh = ret.release();
    return path_handle(nativeh);
  }

current_path()

virtual result<path_type> llfio_v2_xxx::handle::current_path ( ) const

inlinevirtualnoexceptinherited

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.

Warning

This call is expensive, it always asks the kernel for the current path, and no checking is done to ensure what the kernel returns is accurate or even sensible. Be aware that despite these precautions, paths are unstable and can change randomly at any moment. Most code written to use absolute file systems paths is racy, so don't do it, use path_handle to fix a base location on the file system and work from that anchor instead!

Memory Allocations

At least one malloc for the path_type, likely several more.

See also

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 in llfio_v2_xxx::symlink_handle.

path() [1/2]

static result<path_handle> llfio_v2_xxx::path_handle::path ( const path_handle &  base, path_view_type  path  )

inlinestaticnoexcept

Create a path handle opening access to some location on the filing system. Some operating systems provide a particularly lightweight method of doing this (Linux: O_PATH, Windows: no access perms) which is much faster than opening a directory. For other systems, we open a directory with read only permissions.

Errors returnable

Any of the values POSIX open() or CreateFile() can return.

path() [2/2]

static result<path_handle> llfio_v2_xxx::path_handle::path ( path_view_type  _path )

inlinestaticnoexcept

This is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.

{ return path(path_handle(), _path); }

QUICKCPPLIB_BITFIELD_BEGIN()

llfio_v2_xxx::handle::QUICKCPPLIB_BITFIELD_BEGIN ( flag  )

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.

Warning

This does not prevent races where in between the time of checking the inode and executing the unlink a third party changes the item about to be unlinked. Only operating systems with a true race-free unlink syscall are race free.

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.

< On Windows, create any new handles with OVERLAPPED semantics

< Using insane POSIX byte range locks

< This is an inode created with no representation on the filing system

                                  {
  none = 0,  //!< 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.
  */
  unlink_on_first_close = 1U << 0U,

  /*! 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
  */
  disable_safety_barriers = 1U << 2U,
  /*! `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.
  \warning This does not prevent races where in between the time of checking the inode
  and executing the unlink a third party changes the item about to be unlinked. Only
  operating systems with a true race-free unlink syscall are race free.
  */
  disable_safety_unlinks = 1U << 3U,
  /*! Ask the OS to disable prefetching of data. This can improve random
  i/o performance.
  */
  disable_prefetching = 1U << 4U,
  /*! Ask the OS to maximise prefetching of data, possibly prefetching the entire file
  into kernel cache. This can improve sequential i/o performance.
  */
  maximum_prefetching = 1U << 5U,

  win_disable_unlink_emulation = 1U << 24U,  //!< 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.
  */
  win_disable_sparse_file_creation = 1U << 25U,
  /*! 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.
  */
  disable_parallelism = 1U << 26U,
  /*! 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.
  */
  win_create_case_sensitive_directory = 1U << 27U,

  // NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!

  overlapped = 1U << 28U,          //!< On Windows, create any new handles with OVERLAPPED semantics
  byte_lock_insanity = 1U << 29U,  //!< Using insane POSIX byte range locks
  anonymous_inode = 1U << 30U      //!< This is an inode created with no representation on the filing system
  } QUICKCPPLIB_BITFIELD_END(flag);

set_append_only()

virtual result<void> llfio_v2_xxx::handle::set_append_only ( bool  enable )

inlinevirtualnoexceptinherited

Changes whether this handle is append only or not.

Warning

On Windows this is implemented as a bit of a hack to make it fast like on POSIX, so make sure you open the handle for read/write originally. Note unlike on POSIX the append_only disposition will be the only one toggled, seekable and readable will remain turned on.

Errors returnable

Whatever POSIX fcntl() returns. On Windows nothing is changed on the handle.

Memory Allocations

No memory allocation.

---

The documentation for this class was generated from the following file:

• include/llfio/v2.0/path_handle.hpp