diff options
| author | Jenkins nedprod CI <foo@nowhere> | 2018-07-11 21:15:32 +0300 |
|---|---|---|
| committer | Jenkins nedprod CI <foo@nowhere> | 2018-07-11 21:15:32 +0300 |
| commit | 6655470986e33c3bd9d7d362b901346e20db5fee (patch) | |
| tree | b0467efce6d4184fb034079ba822453775573c0e | |
| parent | aeeb2118847430444de632531b8aa9176247bad1 (diff) | |
Travis CI updates documentation
54 files changed, 149 insertions, 149 deletions
diff --git a/annotated.html b/annotated.html index fa55ff1d..b5275010 100644 --- a/annotated.html +++ b/annotated.html @@ -86,7 +86,7 @@ $(document).ready(function(){initNavTree('annotated.html','');}); <div class="contents"> <div class="textblock">Here are the classes, structs, unions and interfaces with brief descriptions:</div><div class="directory"> <div class="levels">[detail level <span onclick="javascript:toggleLevel(1);">1</span><span onclick="javascript:toggleLevel(2);">2</span><span onclick="javascript:toggleLevel(3);">3</span><span onclick="javascript:toggleLevel(4);">4</span><span onclick="javascript:toggleLevel(5);">5</span>]</div><table class="directory"> -<tr id="row_0_" class="even"><td class="entry"><span style="width:0px;display:inline-block;"> </span><span id="arr_0_" class="arrow" onclick="toggleFolder('0_')">▼</span><span class="icona"><span class="icon">N</span></span><a class="el" href="namespacellfio__v2__xxx.html" target="_self">llfio_v2_xxx</a></td><td class="desc">The AFIO namespace </td></tr> +<tr id="row_0_" class="even"><td class="entry"><span style="width:0px;display:inline-block;"> </span><span id="arr_0_" class="arrow" onclick="toggleFolder('0_')">▼</span><span class="icona"><span class="icon">N</span></span><a class="el" href="namespacellfio__v2__xxx.html" target="_self">llfio_v2_xxx</a></td><td class="desc">The LLFIO namespace </td></tr> <tr id="row_0_0_"><td class="entry"><span style="width:16px;display:inline-block;"> </span><span id="arr_0_0_" class="arrow" onclick="toggleFolder('0_0_')">▼</span><span class="icona"><span class="icon">N</span></span><a class="el" href="namespacellfio__v2__xxx_1_1algorithm.html" target="_self">algorithm</a></td><td class="desc">Collection of file system based algorithms </td></tr> <tr id="row_0_0_0_" class="even"><td class="entry"><span style="width:32px;display:inline-block;"> </span><span id="arr_0_0_0_" class="arrow" onclick="toggleFolder('0_0_0_')">▼</span><span class="icona"><span class="icon">N</span></span><a class="el" href="namespacellfio__v2__xxx_1_1algorithm_1_1impl.html" target="_self">impl</a></td><td class="desc">Does not exist in the actual source code, purely here to workaround doxygen limitations </td></tr> <tr id="row_0_0_0_0_"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="structllfio__v2__xxx_1_1algorithm_1_1impl_1_1trivial__vector__impl.html" target="_self">trivial_vector_impl</a></td><td class="desc"></td></tr> @@ -112,7 +112,7 @@ $(document).ready(function(){initNavTree('annotated.html','');}); <tr id="row_0_2_1_"><td class="entry"><span style="width:48px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="structllfio__v2__xxx_1_1storage__profile_1_1item__base.html" target="_self">item_base</a></td><td class="desc">Common base class for items </td></tr> <tr id="row_0_2_2_" class="even"><td class="entry"><span style="width:48px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="structllfio__v2__xxx_1_1storage__profile_1_1item__erased.html" target="_self">item_erased</a></td><td class="desc">A type erased tag-value item </td></tr> <tr id="row_0_2_3_"><td class="entry"><span style="width:48px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="structllfio__v2__xxx_1_1storage__profile_1_1storage__profile.html" target="_self">storage_profile</a></td><td class="desc">A (possibly incomplet) profile of storage </td></tr> -<tr id="row_0_3_" class="even"><td class="entry"><span style="width:16px;display:inline-block;"> </span><span id="arr_0_3_" class="arrow" onclick="toggleFolder('0_3_')">▼</span><span class="icona"><span class="icon">N</span></span><a class="el" href="namespacellfio__v2__xxx_1_1utils.html" target="_self">utils</a></td><td class="desc">Utility routines often useful when using AFIO </td></tr> +<tr id="row_0_3_" class="even"><td class="entry"><span style="width:16px;display:inline-block;"> </span><span id="arr_0_3_" class="arrow" onclick="toggleFolder('0_3_')">▼</span><span class="icona"><span class="icon">N</span></span><a class="el" href="namespacellfio__v2__xxx_1_1utils.html" target="_self">utils</a></td><td class="desc">Utility routines often useful when using LLFIO </td></tr> <tr id="row_0_3_0_"><td class="entry"><span style="width:32px;display:inline-block;"> </span><span id="arr_0_3_0_" class="arrow" onclick="toggleFolder('0_3_0_')">▼</span><span class="icona"><span class="icon">C</span></span><a class="el" href="classllfio__v2__xxx_1_1utils_1_1page__allocator.html" target="_self">page_allocator</a></td><td class="desc">An STL allocator which allocates large TLB page memory.If the operating system is configured to allow it, this type of memory is particularly efficient for doing large scale file i/o. This is because the kernel must normally convert the scatter gather buffers you pass into extended scatter gather buffers as the memory you see as contiguous may not, and probably isn't, actually be contiguous in physical memory. Regions returned by this allocator <em>may</em> be allocated contiguously in physical memory and therefore the kernel can pass through your scatter gather buffers unmodified </td></tr> <tr id="row_0_3_0_0_" class="even"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="structllfio__v2__xxx_1_1utils_1_1page__allocator_1_1rebind.html" target="_self">rebind</a></td><td class="desc"></td></tr> <tr id="row_0_3_1_"><td class="entry"><span style="width:32px;display:inline-block;"> </span><span id="arr_0_3_1_" class="arrow" onclick="toggleFolder('0_3_1_')">▼</span><span class="icona"><span class="icon">C</span></span><a class="el" href="classllfio__v2__xxx_1_1utils_1_1page__allocator_3_01void_01_4.html" target="_self">page_allocator< void ></a></td><td class="desc"></td></tr> @@ -131,7 +131,7 @@ $(document).ready(function(){initNavTree('annotated.html','');}); <tr id="row_0_14_0_" class="even"><td class="entry"><span style="width:48px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="structllfio__v2__xxx_1_1directory__handle_1_1buffers__type.html" target="_self">buffers_type</a></td><td class="desc"></td></tr> <tr id="row_0_14_1_"><td class="entry"><span style="width:48px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="structllfio__v2__xxx_1_1directory__handle_1_1enumerate__info.html" target="_self">enumerate_info</a></td><td class="desc">Completion information for <code>enumerate()</code> </td></tr> <tr id="row_0_15_" class="even"><td class="entry"><span style="width:32px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="classllfio__v2__xxx_1_1error.html" target="_self">error</a></td><td class="desc">The exception type synthesised and thrown when an <code>llfio::result</code> or <code>llfio::outcome</code> is no-value observed </td></tr> -<tr id="row_0_16_"><td class="entry"><span style="width:32px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="structllfio__v2__xxx_1_1error__info.html" target="_self">error_info</a></td><td class="desc">The cause of the failure of an operation in AFIO </td></tr> +<tr id="row_0_16_"><td class="entry"><span style="width:32px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="structllfio__v2__xxx_1_1error__info.html" target="_self">error_info</a></td><td class="desc">The cause of the failure of an operation in LLFIO </td></tr> <tr id="row_0_17_" class="even"><td class="entry"><span style="width:32px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="classllfio__v2__xxx_1_1file__handle.html" target="_self">file_handle</a></td><td class="desc">A handle to a regular file or device, kept data layout compatible with async_file_handle </td></tr> <tr id="row_0_18_"><td class="entry"><span style="width:32px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="classllfio__v2__xxx_1_1fs__handle.html" target="_self">fs_handle</a></td><td class="desc">A handle to something with a device and inode number </td></tr> <tr id="row_0_19_" class="even"><td class="entry"><span style="width:32px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="classllfio__v2__xxx_1_1handle.html" target="_self">handle</a></td><td class="desc">A native_handle_type which is managed by the lifetime of this object instance </td></tr> diff --git a/atomic__append_8hpp.html b/atomic__append_8hpp.html index 5116d820..bc481b6b 100644 --- a/atomic__append_8hpp.html +++ b/atomic__append_8hpp.html @@ -104,7 +104,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:namespacellfio__v2__xxx_1_1algorithm"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx_1_1algorithm.html">llfio_v2_xxx::algorithm</a></td></tr> <tr class="memdesc:namespacellfio__v2__xxx_1_1algorithm"><td class="mdescLeft"> </td><td class="mdescRight">Collection of file system based algorithms. <br /></td></tr> diff --git a/base_8hpp.html b/base_8hpp.html index 121a4202..ab5ca05c 100644 --- a/base_8hpp.html +++ b/base_8hpp.html @@ -109,7 +109,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:namespacellfio__v2__xxx_1_1algorithm"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx_1_1algorithm.html">llfio_v2_xxx::algorithm</a></td></tr> <tr class="memdesc:namespacellfio__v2__xxx_1_1algorithm"><td class="mdescLeft"> </td><td class="mdescRight">Collection of file system based algorithms. <br /></td></tr> diff --git a/byte__ranges_8hpp.html b/byte__ranges_8hpp.html index 81a911ad..9bb16f2c 100644 --- a/byte__ranges_8hpp.html +++ b/byte__ranges_8hpp.html @@ -103,7 +103,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:namespacellfio__v2__xxx_1_1algorithm"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx_1_1algorithm.html">llfio_v2_xxx::algorithm</a></td></tr> <tr class="memdesc:namespacellfio__v2__xxx_1_1algorithm"><td class="mdescLeft"> </td><td class="mdescRight">Collection of file system based algorithms. <br /></td></tr> diff --git a/cached__parent__handle__adapter_8hpp.html b/cached__parent__handle__adapter_8hpp.html index 5068fbe9..b6b5489f 100644 --- a/cached__parent__handle__adapter_8hpp.html +++ b/cached__parent__handle__adapter_8hpp.html @@ -106,7 +106,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:namespacellfio__v2__xxx_1_1algorithm"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx_1_1algorithm.html">llfio_v2_xxx::algorithm</a></td></tr> <tr class="memdesc:namespacellfio__v2__xxx_1_1algorithm"><td class="mdescLeft"> </td><td class="mdescRight">Collection of file system based algorithms. <br /></td></tr> diff --git a/classllfio__v2__xxx_1_1algorithm_1_1shared__fs__mutex_1_1atomic__append.html b/classllfio__v2__xxx_1_1algorithm_1_1shared__fs__mutex_1_1atomic__append.html index 86d826c0..820b2080 100644 --- a/classllfio__v2__xxx_1_1algorithm_1_1shared__fs__mutex_1_1atomic__append.html +++ b/classllfio__v2__xxx_1_1algorithm_1_1shared__fs__mutex_1_1atomic__append.html @@ -204,7 +204,7 @@ Protected Member Functions</h2></td></tr> <li>Similarly older operating systems (e.g. Linux < 3.0) do not implement extent hole punching and therefore will also see excessive disk space consumption. Note at the time of writing OS X doesn't implement hole punching at all.</li> <li>If your OS doesn't have sane byte range locks (OS X, BSD, older Linuxes) and multiple objects in your process use the same lock file, misoperation will occur. Use lock_files instead.</li> </ul> -<dl class="todo"><dt><b><a class="el" href="todo.html#_todo000004">Todo:</a></b></dt><dd><p class="startdd">Implement hole punching once I port that code from AFIO v1. </p> +<dl class="todo"><dt><b><a class="el" href="todo.html#_todo000004">Todo:</a></b></dt><dd><p class="startdd">Implement hole punching once I port that code from LLFIO v1. </p> <p>Decide on some resolution mechanism for sudden process exit. </p> <p class="enddd">There is a 1 out of 2^64-2 chance of unique id collision. It would be nice if we actually formally checked that our chosen unique id is actually unique. </p> </dd></dl> diff --git a/classllfio__v2__xxx_1_1algorithm_1_1shared__fs__mutex_1_1memory__map.html b/classllfio__v2__xxx_1_1algorithm_1_1shared__fs__mutex_1_1memory__map.html index f726fd87..e71d3a52 100644 --- a/classllfio__v2__xxx_1_1algorithm_1_1shared__fs__mutex_1_1memory__map.html +++ b/classllfio__v2__xxx_1_1algorithm_1_1shared__fs__mutex_1_1memory__map.html @@ -221,7 +221,7 @@ class llfio_v2_xxx::algorithm::shared_fs_mutex::memory_map< Hasher, HashIndex </table> </dd> </dl> -<p>This is the highest performing filing system mutex in AFIO, but it comes with a long list of potential gotchas. It works by creating a random temporary file somewhere on the system and placing its path in a file at the lock file location. The random temporary file is mapped into memory by all processes using the lock where an open addressed hash table is kept. Each entity is hashed into somewhere in the hash table and its individual spin lock is used to implement the exclusion. As with <code>byte_ranges</code>, each entity is locked individually in sequence but if a particular lock fails, all are unlocked and the list is randomised before trying again. Because this locking implementation is entirely implemented in userspace using shared memory without any kernel syscalls, performance is probably as fast as any many-arbitrary-entity shared locking system could be.</p> +<p>This is the highest performing filing system mutex in LLFIO, but it comes with a long list of potential gotchas. It works by creating a random temporary file somewhere on the system and placing its path in a file at the lock file location. The random temporary file is mapped into memory by all processes using the lock where an open addressed hash table is kept. Each entity is hashed into somewhere in the hash table and its individual spin lock is used to implement the exclusion. As with <code>byte_ranges</code>, each entity is locked individually in sequence but if a particular lock fails, all are unlocked and the list is randomised before trying again. Because this locking implementation is entirely implemented in userspace using shared memory without any kernel syscalls, performance is probably as fast as any many-arbitrary-entity shared locking system could be.</p> <p>As it uses shared memory, this implementation of <code>shared_fs_mutex</code> cannot work over a networked drive. If you attempt to open this lock on a network drive and the first user of the lock is not on this local machine, <code>errc::no_lock_available</code> will be returned from the constructor.</p> <ul> <li>Linear complexity to number of concurrent users up until hash table starts to get full or hashed entries collide.</li> diff --git a/classllfio__v2__xxx_1_1directory__handle.html b/classllfio__v2__xxx_1_1directory__handle.html index 940c9aab..30c959f2 100644 --- a/classllfio__v2__xxx_1_1directory__handle.html +++ b/classllfio__v2__xxx_1_1directory__handle.html @@ -406,9 +406,9 @@ ino_t </td><td class="memItemRight" valign="bottom"><b>_inode</b> {0}</td>< </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa334c4a4c42fdb79d7ebc3e73b517e6f8"></a>none </td><td class="fielddoc"><p>No caching whatsoever, all reads and writes come from storage (i.e. <code>O_DIRECT|O_SYNC</code>). Align all i/o to 4Kb boundaries for this to work. <code>flag_disable_safety_fsyncs</code> can be used here. </p> </td></tr> -<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962"></a>unlink_on_first_close </td><td class="fielddoc"><p>Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed to by <code>path()</code> upon the call of <code>close()</code> 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 <code>errc::resource_unavailable_try_again</code> error return. Because this is confusing, unless the <code>win_disable_unlink_emulation</code> flag is also specified, this POSIX behaviour is somewhat emulated by AFIO on older Windows by renaming the file to a random name on <code>close()</code> causing it to appear to have been unlinked immediately. </p> +<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962"></a>unlink_on_first_close </td><td class="fielddoc"><p>Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed to by <code>path()</code> upon the call of <code>close()</code> 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 <code>errc::resource_unavailable_try_again</code> error return. Because this is confusing, unless the <code>win_disable_unlink_emulation</code> flag is also specified, this POSIX behaviour is somewhat emulated by LLFIO on older Windows by renaming the file to a random name on <code>close()</code> causing it to appear to have been unlinked immediately. </p> </td></tr> -<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9"></a>disable_safety_fsyncs </td><td class="fielddoc"><p>Some kernel caching modes have unhelpfully inconsistent behaviours in getting your data onto storage, so by default unless this flag is specified AFIO 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.</p> +<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9"></a>disable_safety_fsyncs </td><td class="fielddoc"><p>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.</p> <p>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.</p> <p>This only occurs for these kernel caching modes: caching::none caching::reads caching::reads_and_metadata caching::safety_fsyncs </p> </td></tr> @@ -422,7 +422,7 @@ ino_t </td><td class="memItemRight" valign="bottom"><b>_inode</b> {0}</td>< </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0"></a>win_disable_sparse_file_creation </td><td class="fielddoc"><p>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.</p> <p>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.</p> -<p>As extents-based storage is nearly cost free on NTFS, AFIO 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. </p> +<p>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. </p> </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a"></a>overlapped </td><td class="fielddoc"><p>On Windows, create any new handles with OVERLAPPED semantics. </p> </td></tr> @@ -431,7 +431,7 @@ ino_t </td><td class="memItemRight" valign="bottom"><b>_inode</b> {0}</td>< <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"></a>anonymous_inode </td><td class="fielddoc"><p>This is an inode created with no representation on the filing system. </p> </td></tr> </table> -<div class="fragment"><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>  {</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a> = 0, <span class="comment">//!< No flags</span></div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span> <span class="comment"></span><span class="comment"> /*! Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed</span></div><div class="line"><a name="l00101"></a><span class="lineno"> 101</span> <span class="comment"> to by `path()` upon the call of `close()` if and only if the inode matches. On Windows,</span></div><div class="line"><a name="l00102"></a><span class="lineno"> 102</span> <span class="comment"> if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous</span></div><div class="line"><a name="l00103"></a><span class="lineno"> 103</span> <span class="comment"> editions of Windows, the file entry does not disappears but becomes unavailable for</span></div><div class="line"><a name="l00104"></a><span class="lineno"> 104</span> <span class="comment"> anyone else to open with an `errc::resource_unavailable_try_again` error return. Because this is confusing, unless the</span></div><div class="line"><a name="l00105"></a><span class="lineno"> 105</span> <span class="comment"> `win_disable_unlink_emulation` flag is also specified, this POSIX behaviour is</span></div><div class="line"><a name="l00106"></a><span class="lineno"> 106</span> <span class="comment"> somewhat emulated by AFIO on older Windows by renaming the file to a random name on `close()`</span></div><div class="line"><a name="l00107"></a><span class="lineno"> 107</span> <span class="comment"> causing it to appear to have been unlinked immediately.</span></div><div class="line"><a name="l00108"></a><span class="lineno"> 108</span> <span class="comment"> */</span></div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">unlink_on_first_close</a> = 1U << 0U,</div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span> <span class="comment"></span></div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span> <span class="comment"> /*! Some kernel caching modes have unhelpfully inconsistent behaviours</span></div><div class="line"><a name="l00112"></a><span class="lineno"> 112</span> <span class="comment"> in getting your data onto storage, so by default unless this flag is</span></div><div class="line"><a name="l00113"></a><span class="lineno"> 113</span> <span class="comment"> specified AFIO adds extra fsyncs to the following operations for the</span></div><div class="line"><a name="l00114"></a><span class="lineno"> 114</span> <span class="comment"> caching modes specified below:</span></div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span> <span class="comment"> * truncation of file length either explicitly or during file open.</span></div><div class="line"><a name="l00116"></a><span class="lineno"> 116</span> <span class="comment"> * closing of the handle either explicitly or in the destructor.</span></div><div class="line"><a name="l00117"></a><span class="lineno"> 117</span> <span class="comment"></span></div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span> <span class="comment"> Additionally on Linux only to prevent loss of file metadata:</span></div><div class="line"><a name="l00119"></a><span class="lineno"> 119</span> <span class="comment"> * On the parent directory whenever a file might have been created.</span></div><div class="line"><a name="l00120"></a><span class="lineno"> 120</span> <span class="comment"> * On the parent directory on file close.</span></div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span> <span class="comment"></span></div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span> <span class="comment"> This only occurs for these kernel caching modes:</span></div><div class="line"><a name="l00123"></a><span class="lineno"> 123</span> <span class="comment"> * caching::none</span></div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span> <span class="comment"> * caching::reads</span></div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span> <span class="comment"> * caching::reads_and_metadata</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> <span class="comment"> * caching::safety_fsyncs</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> <span class="comment"> */</span></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9">disable_safety_fsyncs</a> = 1U << 2U,<span class="comment"></span></div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span> <span class="comment"> /*! `file_handle::unlink()` could accidentally delete the wrong file if someone has</span></div><div class="line"><a name="l00130"></a><span class="lineno"> 130</span> <span class="comment"> renamed the open file handle since the time it was opened. To prevent this occuring,</span></div><div class="line"><a name="l00131"></a><span class="lineno"> 131</span> <span class="comment"> where the OS doesn't provide race free unlink-by-open-handle we compare the inode of</span></div><div class="line"><a name="l00132"></a><span class="lineno"> 132</span> <span class="comment"> the path we are about to unlink with that of the open handle before unlinking.</span></div><div class="line"><a name="l00133"></a><span class="lineno"> 133</span> <span class="comment"> \warning This does not prevent races where in between the time of checking the inode</span></div><div class="line"><a name="l00134"></a><span class="lineno"> 134</span> <span class="comment"> and executing the unlink a third party changes the item about to be unlinked. Only</span></div><div class="line"><a name="l00135"></a><span class="lineno"> 135</span> <span class="comment"> operating systems with a true race-free unlink syscall are race free.</span></div><div class="line"><a name="l00136"></a><span class="lineno"> 136</span> <span class="comment"> */</span></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">disable_safety_unlinks</a> = 1U << 3U,<span class="comment"></span></div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span> <span class="comment"> /*! Ask the OS to disable prefetching of data. This can improve random</span></div><div class="line"><a name="l00139"></a><span class="lineno"> 139</span> <span class="comment"> i/o performance.</span></div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span> <span class="comment"> */</span></div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">disable_prefetching</a> = 1U << 4U,<span class="comment"></span></div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span> <span class="comment"> /*! Ask the OS to maximise prefetching of data, possibly prefetching the entire file</span></div><div class="line"><a name="l00143"></a><span class="lineno"> 143</span> <span class="comment"> into kernel cache. This can improve sequential i/o performance.</span></div><div class="line"><a name="l00144"></a><span class="lineno"> 144</span> <span class="comment"> */</span></div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">maximum_prefetching</a> = 1U << 5U,</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span> </div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">win_disable_unlink_emulation</a> = 1U << 24U, <span class="comment">//!< See the documentation for `unlink_on_first_close`</span></div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span> <span class="comment"></span><span class="comment"> /*! Microsoft Windows NTFS, having been created in the late 1980s, did not originally</span></div><div class="line"><a name="l00149"></a><span class="lineno"> 149</span> <span class="comment"> implement extents-based storage and thus could only represent sparse files via</span></div><div class="line"><a name="l00150"></a><span class="lineno"> 150</span> <span class="comment"> efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000),</span></div><div class="line"><a name="l00151"></a><span class="lineno"> 151</span> <span class="comment"> a proper extents-based on-storage representation was added, thus allowing only 64Kb</span></div><div class="line"><a name="l00152"></a><span class="lineno"> 152</span> <span class="comment"> extent chunks written to be stored irrespective of whatever the maximum file extent</span></div><div class="line"><a name="l00153"></a><span class="lineno"> 153</span> <span class="comment"> was set to.</span></div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span> <span class="comment"></span></div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span> <span class="comment"> For various historical reasons, extents-based storage is disabled by default in newly</span></div><div class="line"><a name="l00156"></a><span class="lineno"> 156</span> <span class="comment"> created files on NTFS, unlike in almost every other major filing system. You have to</span></div><div class="line"><a name="l00157"></a><span class="lineno"> 157</span> <span class="comment"> explicitly "opt in" to extents-based storage.</span></div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span> <span class="comment"></span></div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span> <span class="comment"> As extents-based storage is nearly cost free on NTFS, AFIO by default opts in to</span></div><div class="line"><a name="l00160"></a><span class="lineno"> 160</span> <span class="comment"> extents-based storage for any empty file it creates. If you don't want this, you</span></div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span> <span class="comment"> can specify this flag to prevent that happening.</span></div><div class="line"><a name="l00162"></a><span class="lineno"> 162</span> <span class="comment"> */</span></div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">win_disable_sparse_file_creation</a> = 1U << 25U,</div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span> </div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span>  <span class="comment">// NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!</span></div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span> </div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">overlapped</a> = 1U << 28U, <span class="comment">//!< On Windows, create any new handles with OVERLAPPED semantics</span></div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">byte_lock_insanity</a> = 1U << 29U, <span class="comment">//!< Using insane POSIX byte range locks</span></div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">anonymous_inode</a> = 1U << 30U <span class="comment">//!< This is an inode created with no representation on the filing system</span></div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span> <span class="comment"></span> }</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">llfio_v2_xxx::handle::anonymous_inode</a></div><div class="ttdoc">This is an inode created with no representation on the filing system. </div><div class="ttdef"><b>Definition:</b> handle.hpp:169</div></div> +<div class="fragment"><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>  {</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a> = 0, <span class="comment">//!< No flags</span></div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span> <span class="comment"></span><span class="comment"> /*! Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed</span></div><div class="line"><a name="l00101"></a><span class="lineno"> 101</span> <span class="comment"> to by `path()` upon the call of `close()` if and only if the inode matches. On Windows,</span></div><div class="line"><a name="l00102"></a><span class="lineno"> 102</span> <span class="comment"> if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous</span></div><div class="line"><a name="l00103"></a><span class="lineno"> 103</span> <span class="comment"> editions of Windows, the file entry does not disappears but becomes unavailable for</span></div><div class="line"><a name="l00104"></a><span class="lineno"> 104</span> <span class="comment"> anyone else to open with an `errc::resource_unavailable_try_again` error return. Because this is confusing, unless the</span></div><div class="line"><a name="l00105"></a><span class="lineno"> 105</span> <span class="comment"> `win_disable_unlink_emulation` flag is also specified, this POSIX behaviour is</span></div><div class="line"><a name="l00106"></a><span class="lineno"> 106</span> <span class="comment"> somewhat emulated by LLFIO on older Windows by renaming the file to a random name on `close()`</span></div><div class="line"><a name="l00107"></a><span class="lineno"> 107</span> <span class="comment"> causing it to appear to have been unlinked immediately.</span></div><div class="line"><a name="l00108"></a><span class="lineno"> 108</span> <span class="comment"> */</span></div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">unlink_on_first_close</a> = 1U << 0U,</div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span> <span class="comment"></span></div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span> <span class="comment"> /*! Some kernel caching modes have unhelpfully inconsistent behaviours</span></div><div class="line"><a name="l00112"></a><span class="lineno"> 112</span> <span class="comment"> in getting your data onto storage, so by default unless this flag is</span></div><div class="line"><a name="l00113"></a><span class="lineno"> 113</span> <span class="comment"> specified LLFIO adds extra fsyncs to the following operations for the</span></div><div class="line"><a name="l00114"></a><span class="lineno"> 114</span> <span class="comment"> caching modes specified below:</span></div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span> <span class="comment"> * truncation of file length either explicitly or during file open.</span></div><div class="line"><a name="l00116"></a><span class="lineno"> 116</span> <span class="comment"> * closing of the handle either explicitly or in the destructor.</span></div><div class="line"><a name="l00117"></a><span class="lineno"> 117</span> <span class="comment"></span></div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span> <span class="comment"> Additionally on Linux only to prevent loss of file metadata:</span></div><div class="line"><a name="l00119"></a><span class="lineno"> 119</span> <span class="comment"> * On the parent directory whenever a file might have been created.</span></div><div class="line"><a name="l00120"></a><span class="lineno"> 120</span> <span class="comment"> * On the parent directory on file close.</span></div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span> <span class="comment"></span></div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span> <span class="comment"> This only occurs for these kernel caching modes:</span></div><div class="line"><a name="l00123"></a><span class="lineno"> 123</span> <span class="comment"> * caching::none</span></div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span> <span class="comment"> * caching::reads</span></div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span> <span class="comment"> * caching::reads_and_metadata</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> <span class="comment"> * caching::safety_fsyncs</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> <span class="comment"> */</span></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9">disable_safety_fsyncs</a> = 1U << 2U,<span class="comment"></span></div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span> <span class="comment"> /*! `file_handle::unlink()` could accidentally delete the wrong file if someone has</span></div><div class="line"><a name="l00130"></a><span class="lineno"> 130</span> <span class="comment"> renamed the open file handle since the time it was opened. To prevent this occuring,</span></div><div class="line"><a name="l00131"></a><span class="lineno"> 131</span> <span class="comment"> where the OS doesn't provide race free unlink-by-open-handle we compare the inode of</span></div><div class="line"><a name="l00132"></a><span class="lineno"> 132</span> <span class="comment"> the path we are about to unlink with that of the open handle before unlinking.</span></div><div class="line"><a name="l00133"></a><span class="lineno"> 133</span> <span class="comment"> \warning This does not prevent races where in between the time of checking the inode</span></div><div class="line"><a name="l00134"></a><span class="lineno"> 134</span> <span class="comment"> and executing the unlink a third party changes the item about to be unlinked. Only</span></div><div class="line"><a name="l00135"></a><span class="lineno"> 135</span> <span class="comment"> operating systems with a true race-free unlink syscall are race free.</span></div><div class="line"><a name="l00136"></a><span class="lineno"> 136</span> <span class="comment"> */</span></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">disable_safety_unlinks</a> = 1U << 3U,<span class="comment"></span></div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span> <span class="comment"> /*! Ask the OS to disable prefetching of data. This can improve random</span></div><div class="line"><a name="l00139"></a><span class="lineno"> 139</span> <span class="comment"> i/o performance.</span></div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span> <span class="comment"> */</span></div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">disable_prefetching</a> = 1U << 4U,<span class="comment"></span></div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span> <span class="comment"> /*! Ask the OS to maximise prefetching of data, possibly prefetching the entire file</span></div><div class="line"><a name="l00143"></a><span class="lineno"> 143</span> <span class="comment"> into kernel cache. This can improve sequential i/o performance.</span></div><div class="line"><a name="l00144"></a><span class="lineno"> 144</span> <span class="comment"> */</span></div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">maximum_prefetching</a> = 1U << 5U,</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span> </div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">win_disable_unlink_emulation</a> = 1U << 24U, <span class="comment">//!< See the documentation for `unlink_on_first_close`</span></div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span> <span class="comment"></span><span class="comment"> /*! Microsoft Windows NTFS, having been created in the late 1980s, did not originally</span></div><div class="line"><a name="l00149"></a><span class="lineno"> 149</span> <span class="comment"> implement extents-based storage and thus could only represent sparse files via</span></div><div class="line"><a name="l00150"></a><span class="lineno"> 150</span> <span class="comment"> efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000),</span></div><div class="line"><a name="l00151"></a><span class="lineno"> 151</span> <span class="comment"> a proper extents-based on-storage representation was added, thus allowing only 64Kb</span></div><div class="line"><a name="l00152"></a><span class="lineno"> 152</span> <span class="comment"> extent chunks written to be stored irrespective of whatever the maximum file extent</span></div><div class="line"><a name="l00153"></a><span class="lineno"> 153</span> <span class="comment"> was set to.</span></div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span> <span class="comment"></span></div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span> <span class="comment"> For various historical reasons, extents-based storage is disabled by default in newly</span></div><div class="line"><a name="l00156"></a><span class="lineno"> 156</span> <span class="comment"> created files on NTFS, unlike in almost every other major filing system. You have to</span></div><div class="line"><a name="l00157"></a><span class="lineno"> 157</span> <span class="comment"> explicitly "opt in" to extents-based storage.</span></div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span> <span class="comment"></span></div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span> <span class="comment"> As extents-based storage is nearly cost free on NTFS, LLFIO by default opts in to</span></div><div class="line"><a name="l00160"></a><span class="lineno"> 160</span> <span class="comment"> extents-based storage for any empty file it creates. If you don't want this, you</span></div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span> <span class="comment"> can specify this flag to prevent that happening.</span></div><div class="line"><a name="l00162"></a><span class="lineno"> 162</span> <span class="comment"> */</span></div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">win_disable_sparse_file_creation</a> = 1U << 25U,</div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span> </div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span>  <span class="comment">// NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!</span></div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span> </div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">overlapped</a> = 1U << 28U, <span class="comment">//!< On Windows, create any new handles with OVERLAPPED semantics</span></div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">byte_lock_insanity</a> = 1U << 29U, <span class="comment">//!< Using insane POSIX byte range locks</span></div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">anonymous_inode</a> = 1U << 30U <span class="comment">//!< This is an inode created with no representation on the filing system</span></div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span> <span class="comment"></span> }</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">llfio_v2_xxx::handle::anonymous_inode</a></div><div class="ttdoc">This is an inode created with no representation on the filing system. </div><div class="ttdef"><b>Definition:</b> handle.hpp:169</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">llfio_v2_xxx::handle::disable_safety_unlinks</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:137</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">llfio_v2_xxx::handle::none</a></div><div class="ttdoc">No flags. </div><div class="ttdef"><b>Definition:</b> handle.hpp:99</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">llfio_v2_xxx::handle::maximum_prefetching</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:145</div></div> @@ -469,10 +469,10 @@ ino_t </td><td class="memItemRight" valign="bottom"><b>_inode</b> {0}</td>< <table class="fieldtable"> <tr><th colspan="2">Enumerator</th></tr><tr><td class="fieldname"><a id="a54d63e0972dee77ef1f0ff14bd4f9207a334c4a4c42fdb79d7ebc3e73b517e6f8"></a>none </td><td class="fielddoc"><p>Do no filtering at all. </p> </td></tr> -<tr><td class="fieldname"><a id="a54d63e0972dee77ef1f0ff14bd4f9207a14847befc159c1492671b53718fc46f8"></a>fastdeleted </td><td class="fielddoc"><p>Filter out AFIO deleted files based on their filename (fast and fairly reliable) </p> +<tr><td class="fieldname"><a id="a54d63e0972dee77ef1f0ff14bd4f9207a14847befc159c1492671b53718fc46f8"></a>fastdeleted </td><td class="fielddoc"><p>Filter out LLFIO deleted files based on their filename (fast and fairly reliable) </p> </td></tr> </table> -<div class="fragment"><div class="line"><a name="l00124"></a><span class="lineno"> 124</span>  {</div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a>, <span class="comment">//!< Do no filtering at all</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> <span class="comment"></span> fastdeleted <span class="comment">//!< Filter out AFIO deleted files based on their filename (fast and fairly reliable)</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> <span class="comment"></span> };</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">llfio_v2_xxx::handle::none</a></div><div class="ttdoc">No flags. </div><div class="ttdef"><b>Definition:</b> handle.hpp:99</div></div> +<div class="fragment"><div class="line"><a name="l00124"></a><span class="lineno"> 124</span>  {</div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a>, <span class="comment">//!< Do no filtering at all</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> <span class="comment"></span> fastdeleted <span class="comment">//!< Filter out LLFIO deleted files based on their filename (fast and fairly reliable)</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> <span class="comment"></span> };</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">llfio_v2_xxx::handle::none</a></div><div class="ttdoc">No flags. </div><div class="ttdef"><b>Definition:</b> handle.hpp:99</div></div> </div><!-- fragment --> </div> </div> @@ -601,8 +601,8 @@ ino_t </td><td class="memItemRight" valign="bottom"><b>_inode</b> {0}</td>< </table> </div><div class="memdoc"> <p>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.</p> -<p>If AFIO 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, AFIO 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 <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> -<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in AFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call AFIO appropriately.</p> +<p>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 <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> +<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in LLFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call LLFIO appropriately.</p> <dl class="section warning"><dt>Warning</dt><dd>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 <b>can change randomly at any moment</b>. Most code written to use absolute file systems paths is <b>racy</b>, so don't do it, use <code>path_handle</code> to fix a base location on the file system and work from that anchor instead!</dd></dl> <dl class="section user"><dt>Memory Allocations</dt><dd>At least one malloc for the <code>path_type</code>, likely several more. </dd></dl> <dl class="section see"><dt>See also</dt><dd><code>algorithm::cached_parent_handle_adapter<T></code> 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. </dd></dl> diff --git a/classllfio__v2__xxx_1_1file__handle.html b/classllfio__v2__xxx_1_1file__handle.html index 8da42995..9454f14d 100644 --- a/classllfio__v2__xxx_1_1file__handle.html +++ b/classllfio__v2__xxx_1_1file__handle.html @@ -461,9 +461,9 @@ ino_t </td><td class="memItemRight" valign="bottom"><b>_inode</b> {0}</td>< </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa334c4a4c42fdb79d7ebc3e73b517e6f8"></a>none </td><td class="fielddoc"><p>No caching whatsoever, all reads and writes come from storage (i.e. <code>O_DIRECT|O_SYNC</code>). Align all i/o to 4Kb boundaries for this to work. <code>flag_disable_safety_fsyncs</code> can be used here. </p> </td></tr> -<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962"></a>unlink_on_first_close </td><td class="fielddoc"><p>Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed to by <code>path()</code> upon the call of <code>close()</code> 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 <code>errc::resource_unavailable_try_again</code> error return. Because this is confusing, unless the <code>win_disable_unlink_emulation</code> flag is also specified, this POSIX behaviour is somewhat emulated by AFIO on older Windows by renaming the file to a random name on <code>close()</code> causing it to appear to have been unlinked immediately. </p> +<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962"></a>unlink_on_first_close </td><td class="fielddoc"><p>Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed to by <code>path()</code> upon the call of <code>close()</code> 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 <code>errc::resource_unavailable_try_again</code> error return. Because this is confusing, unless the <code>win_disable_unlink_emulation</code> flag is also specified, this POSIX behaviour is somewhat emulated by LLFIO on older Windows by renaming the file to a random name on <code>close()</code> causing it to appear to have been unlinked immediately. </p> </td></tr> -<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9"></a>disable_safety_fsyncs </td><td class="fielddoc"><p>Some kernel caching modes have unhelpfully inconsistent behaviours in getting your data onto storage, so by default unless this flag is specified AFIO 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.</p> +<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9"></a>disable_safety_fsyncs </td><td class="fielddoc"><p>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.</p> <p>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.</p> <p>This only occurs for these kernel caching modes: caching::none caching::reads caching::reads_and_metadata caching::safety_fsyncs </p> </td></tr> @@ -477,7 +477,7 @@ ino_t </td><td class="memItemRight" valign="bottom"><b>_inode</b> {0}</td>< </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0"></a>win_disable_sparse_file_creation </td><td class="fielddoc"><p>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.</p> <p>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.</p> -<p>As extents-based storage is nearly cost free on NTFS, AFIO 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. </p> +<p>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. </p> </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a"></a>overlapped </td><td class="fielddoc"><p>On Windows, create any new handles with OVERLAPPED semantics. </p> </td></tr> @@ -486,7 +486,7 @@ ino_t </td><td class="memItemRight" valign="bottom"><b>_inode</b> {0}</td>< <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"></a>anonymous_inode </td><td class="fielddoc"><p>This is an inode created with no representation on the filing system. </p> </td></tr> </table> -<div class="fragment"><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>  {</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a> = 0, <span class="comment">//!< No flags</span></div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span> <span class="comment"></span><span class="comment"> /*! Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed</span></div><div class="line"><a name="l00101"></a><span class="lineno"> 101</span> <span class="comment"> to by `path()` upon the call of `close()` if and only if the inode matches. On Windows,</span></div><div class="line"><a name="l00102"></a><span class="lineno"> 102</span> <span class="comment"> if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous</span></div><div class="line"><a name="l00103"></a><span class="lineno"> 103</span> <span class="comment"> editions of Windows, the file entry does not disappears but becomes unavailable for</span></div><div class="line"><a name="l00104"></a><span class="lineno"> 104</span> <span class="comment"> anyone else to open with an `errc::resource_unavailable_try_again` error return. Because this is confusing, unless the</span></div><div class="line"><a name="l00105"></a><span class="lineno"> 105</span> <span class="comment"> `win_disable_unlink_emulation` flag is also specified, this POSIX behaviour is</span></div><div class="line"><a name="l00106"></a><span class="lineno"> 106</span> <span class="comment"> somewhat emulated by AFIO on older Windows by renaming the file to a random name on `close()`</span></div><div class="line"><a name="l00107"></a><span class="lineno"> 107</span> <span class="comment"> causing it to appear to have been unlinked immediately.</span></div><div class="line"><a name="l00108"></a><span class="lineno"> 108</span> <span class="comment"> */</span></div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">unlink_on_first_close</a> = 1U << 0U,</div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span> <span class="comment"></span></div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span> <span class="comment"> /*! Some kernel caching modes have unhelpfully inconsistent behaviours</span></div><div class="line"><a name="l00112"></a><span class="lineno"> 112</span> <span class="comment"> in getting your data onto storage, so by default unless this flag is</span></div><div class="line"><a name="l00113"></a><span class="lineno"> 113</span> <span class="comment"> specified AFIO adds extra fsyncs to the following operations for the</span></div><div class="line"><a name="l00114"></a><span class="lineno"> 114</span> <span class="comment"> caching modes specified below:</span></div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span> <span class="comment"> * truncation of file length either explicitly or during file open.</span></div><div class="line"><a name="l00116"></a><span class="lineno"> 116</span> <span class="comment"> * closing of the handle either explicitly or in the destructor.</span></div><div class="line"><a name="l00117"></a><span class="lineno"> 117</span> <span class="comment"></span></div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span> <span class="comment"> Additionally on Linux only to prevent loss of file metadata:</span></div><div class="line"><a name="l00119"></a><span class="lineno"> 119</span> <span class="comment"> * On the parent directory whenever a file might have been created.</span></div><div class="line"><a name="l00120"></a><span class="lineno"> 120</span> <span class="comment"> * On the parent directory on file close.</span></div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span> <span class="comment"></span></div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span> <span class="comment"> This only occurs for these kernel caching modes:</span></div><div class="line"><a name="l00123"></a><span class="lineno"> 123</span> <span class="comment"> * caching::none</span></div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span> <span class="comment"> * caching::reads</span></div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span> <span class="comment"> * caching::reads_and_metadata</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> <span class="comment"> * caching::safety_fsyncs</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> <span class="comment"> */</span></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9">disable_safety_fsyncs</a> = 1U << 2U,<span class="comment"></span></div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span> <span class="comment"> /*! `file_handle::unlink()` could accidentally delete the wrong file if someone has</span></div><div class="line"><a name="l00130"></a><span class="lineno"> 130</span> <span class="comment"> renamed the open file handle since the time it was opened. To prevent this occuring,</span></div><div class="line"><a name="l00131"></a><span class="lineno"> 131</span> <span class="comment"> where the OS doesn't provide race free unlink-by-open-handle we compare the inode of</span></div><div class="line"><a name="l00132"></a><span class="lineno"> 132</span> <span class="comment"> the path we are about to unlink with that of the open handle before unlinking.</span></div><div class="line"><a name="l00133"></a><span class="lineno"> 133</span> <span class="comment"> \warning This does not prevent races where in between the time of checking the inode</span></div><div class="line"><a name="l00134"></a><span class="lineno"> 134</span> <span class="comment"> and executing the unlink a third party changes the item about to be unlinked. Only</span></div><div class="line"><a name="l00135"></a><span class="lineno"> 135</span> <span class="comment"> operating systems with a true race-free unlink syscall are race free.</span></div><div class="line"><a name="l00136"></a><span class="lineno"> 136</span> <span class="comment"> */</span></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">disable_safety_unlinks</a> = 1U << 3U,<span class="comment"></span></div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span> <span class="comment"> /*! Ask the OS to disable prefetching of data. This can improve random</span></div><div class="line"><a name="l00139"></a><span class="lineno"> 139</span> <span class="comment"> i/o performance.</span></div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span> <span class="comment"> */</span></div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">disable_prefetching</a> = 1U << 4U,<span class="comment"></span></div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span> <span class="comment"> /*! Ask the OS to maximise prefetching of data, possibly prefetching the entire file</span></div><div class="line"><a name="l00143"></a><span class="lineno"> 143</span> <span class="comment"> into kernel cache. This can improve sequential i/o performance.</span></div><div class="line"><a name="l00144"></a><span class="lineno"> 144</span> <span class="comment"> */</span></div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">maximum_prefetching</a> = 1U << 5U,</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span> </div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">win_disable_unlink_emulation</a> = 1U << 24U, <span class="comment">//!< See the documentation for `unlink_on_first_close`</span></div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span> <span class="comment"></span><span class="comment"> /*! Microsoft Windows NTFS, having been created in the late 1980s, did not originally</span></div><div class="line"><a name="l00149"></a><span class="lineno"> 149</span> <span class="comment"> implement extents-based storage and thus could only represent sparse files via</span></div><div class="line"><a name="l00150"></a><span class="lineno"> 150</span> <span class="comment"> efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000),</span></div><div class="line"><a name="l00151"></a><span class="lineno"> 151</span> <span class="comment"> a proper extents-based on-storage representation was added, thus allowing only 64Kb</span></div><div class="line"><a name="l00152"></a><span class="lineno"> 152</span> <span class="comment"> extent chunks written to be stored irrespective of whatever the maximum file extent</span></div><div class="line"><a name="l00153"></a><span class="lineno"> 153</span> <span class="comment"> was set to.</span></div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span> <span class="comment"></span></div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span> <span class="comment"> For various historical reasons, extents-based storage is disabled by default in newly</span></div><div class="line"><a name="l00156"></a><span class="lineno"> 156</span> <span class="comment"> created files on NTFS, unlike in almost every other major filing system. You have to</span></div><div class="line"><a name="l00157"></a><span class="lineno"> 157</span> <span class="comment"> explicitly "opt in" to extents-based storage.</span></div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span> <span class="comment"></span></div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span> <span class="comment"> As extents-based storage is nearly cost free on NTFS, AFIO by default opts in to</span></div><div class="line"><a name="l00160"></a><span class="lineno"> 160</span> <span class="comment"> extents-based storage for any empty file it creates. If you don't want this, you</span></div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span> <span class="comment"> can specify this flag to prevent that happening.</span></div><div class="line"><a name="l00162"></a><span class="lineno"> 162</span> <span class="comment"> */</span></div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">win_disable_sparse_file_creation</a> = 1U << 25U,</div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span> </div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span>  <span class="comment">// NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!</span></div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span> </div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">overlapped</a> = 1U << 28U, <span class="comment">//!< On Windows, create any new handles with OVERLAPPED semantics</span></div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">byte_lock_insanity</a> = 1U << 29U, <span class="comment">//!< Using insane POSIX byte range locks</span></div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">anonymous_inode</a> = 1U << 30U <span class="comment">//!< This is an inode created with no representation on the filing system</span></div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span> <span class="comment"></span> }</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">llfio_v2_xxx::handle::anonymous_inode</a></div><div class="ttdoc">This is an inode created with no representation on the filing system. </div><div class="ttdef"><b>Definition:</b> handle.hpp:169</div></div> +<div class="fragment"><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>  {</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a> = 0, <span class="comment">//!< No flags</span></div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span> <span class="comment"></span><span class="comment"> /*! Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed</span></div><div class="line"><a name="l00101"></a><span class="lineno"> 101</span> <span class="comment"> to by `path()` upon the call of `close()` if and only if the inode matches. On Windows,</span></div><div class="line"><a name="l00102"></a><span class="lineno"> 102</span> <span class="comment"> if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous</span></div><div class="line"><a name="l00103"></a><span class="lineno"> 103</span> <span class="comment"> editions of Windows, the file entry does not disappears but becomes unavailable for</span></div><div class="line"><a name="l00104"></a><span class="lineno"> 104</span> <span class="comment"> anyone else to open with an `errc::resource_unavailable_try_again` error return. Because this is confusing, unless the</span></div><div class="line"><a name="l00105"></a><span class="lineno"> 105</span> <span class="comment"> `win_disable_unlink_emulation` flag is also specified, this POSIX behaviour is</span></div><div class="line"><a name="l00106"></a><span class="lineno"> 106</span> <span class="comment"> somewhat emulated by LLFIO on older Windows by renaming the file to a random name on `close()`</span></div><div class="line"><a name="l00107"></a><span class="lineno"> 107</span> <span class="comment"> causing it to appear to have been unlinked immediately.</span></div><div class="line"><a name="l00108"></a><span class="lineno"> 108</span> <span class="comment"> */</span></div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">unlink_on_first_close</a> = 1U << 0U,</div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span> <span class="comment"></span></div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span> <span class="comment"> /*! Some kernel caching modes have unhelpfully inconsistent behaviours</span></div><div class="line"><a name="l00112"></a><span class="lineno"> 112</span> <span class="comment"> in getting your data onto storage, so by default unless this flag is</span></div><div class="line"><a name="l00113"></a><span class="lineno"> 113</span> <span class="comment"> specified LLFIO adds extra fsyncs to the following operations for the</span></div><div class="line"><a name="l00114"></a><span class="lineno"> 114</span> <span class="comment"> caching modes specified below:</span></div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span> <span class="comment"> * truncation of file length either explicitly or during file open.</span></div><div class="line"><a name="l00116"></a><span class="lineno"> 116</span> <span class="comment"> * closing of the handle either explicitly or in the destructor.</span></div><div class="line"><a name="l00117"></a><span class="lineno"> 117</span> <span class="comment"></span></div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span> <span class="comment"> Additionally on Linux only to prevent loss of file metadata:</span></div><div class="line"><a name="l00119"></a><span class="lineno"> 119</span> <span class="comment"> * On the parent directory whenever a file might have been created.</span></div><div class="line"><a name="l00120"></a><span class="lineno"> 120</span> <span class="comment"> * On the parent directory on file close.</span></div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span> <span class="comment"></span></div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span> <span class="comment"> This only occurs for these kernel caching modes:</span></div><div class="line"><a name="l00123"></a><span class="lineno"> 123</span> <span class="comment"> * caching::none</span></div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span> <span class="comment"> * caching::reads</span></div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span> <span class="comment"> * caching::reads_and_metadata</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> <span class="comment"> * caching::safety_fsyncs</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> <span class="comment"> */</span></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9">disable_safety_fsyncs</a> = 1U << 2U,<span class="comment"></span></div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span> <span class="comment"> /*! `file_handle::unlink()` could accidentally delete the wrong file if someone has</span></div><div class="line"><a name="l00130"></a><span class="lineno"> 130</span> <span class="comment"> renamed the open file handle since the time it was opened. To prevent this occuring,</span></div><div class="line"><a name="l00131"></a><span class="lineno"> 131</span> <span class="comment"> where the OS doesn't provide race free unlink-by-open-handle we compare the inode of</span></div><div class="line"><a name="l00132"></a><span class="lineno"> 132</span> <span class="comment"> the path we are about to unlink with that of the open handle before unlinking.</span></div><div class="line"><a name="l00133"></a><span class="lineno"> 133</span> <span class="comment"> \warning This does not prevent races where in between the time of checking the inode</span></div><div class="line"><a name="l00134"></a><span class="lineno"> 134</span> <span class="comment"> and executing the unlink a third party changes the item about to be unlinked. Only</span></div><div class="line"><a name="l00135"></a><span class="lineno"> 135</span> <span class="comment"> operating systems with a true race-free unlink syscall are race free.</span></div><div class="line"><a name="l00136"></a><span class="lineno"> 136</span> <span class="comment"> */</span></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">disable_safety_unlinks</a> = 1U << 3U,<span class="comment"></span></div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span> <span class="comment"> /*! Ask the OS to disable prefetching of data. This can improve random</span></div><div class="line"><a name="l00139"></a><span class="lineno"> 139</span> <span class="comment"> i/o performance.</span></div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span> <span class="comment"> */</span></div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">disable_prefetching</a> = 1U << 4U,<span class="comment"></span></div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span> <span class="comment"> /*! Ask the OS to maximise prefetching of data, possibly prefetching the entire file</span></div><div class="line"><a name="l00143"></a><span class="lineno"> 143</span> <span class="comment"> into kernel cache. This can improve sequential i/o performance.</span></div><div class="line"><a name="l00144"></a><span class="lineno"> 144</span> <span class="comment"> */</span></div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">maximum_prefetching</a> = 1U << 5U,</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span> </div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">win_disable_unlink_emulation</a> = 1U << 24U, <span class="comment">//!< See the documentation for `unlink_on_first_close`</span></div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span> <span class="comment"></span><span class="comment"> /*! Microsoft Windows NTFS, having been created in the late 1980s, did not originally</span></div><div class="line"><a name="l00149"></a><span class="lineno"> 149</span> <span class="comment"> implement extents-based storage and thus could only represent sparse files via</span></div><div class="line"><a name="l00150"></a><span class="lineno"> 150</span> <span class="comment"> efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000),</span></div><div class="line"><a name="l00151"></a><span class="lineno"> 151</span> <span class="comment"> a proper extents-based on-storage representation was added, thus allowing only 64Kb</span></div><div class="line"><a name="l00152"></a><span class="lineno"> 152</span> <span class="comment"> extent chunks written to be stored irrespective of whatever the maximum file extent</span></div><div class="line"><a name="l00153"></a><span class="lineno"> 153</span> <span class="comment"> was set to.</span></div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span> <span class="comment"></span></div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span> <span class="comment"> For various historical reasons, extents-based storage is disabled by default in newly</span></div><div class="line"><a name="l00156"></a><span class="lineno"> 156</span> <span class="comment"> created files on NTFS, unlike in almost every other major filing system. You have to</span></div><div class="line"><a name="l00157"></a><span class="lineno"> 157</span> <span class="comment"> explicitly "opt in" to extents-based storage.</span></div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span> <span class="comment"></span></div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span> <span class="comment"> As extents-based storage is nearly cost free on NTFS, LLFIO by default opts in to</span></div><div class="line"><a name="l00160"></a><span class="lineno"> 160</span> <span class="comment"> extents-based storage for any empty file it creates. If you don't want this, you</span></div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span> <span class="comment"> can specify this flag to prevent that happening.</span></div><div class="line"><a name="l00162"></a><span class="lineno"> 162</span> <span class="comment"> */</span></div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">win_disable_sparse_file_creation</a> = 1U << 25U,</div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span> </div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span>  <span class="comment">// NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!</span></div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span> </div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">overlapped</a> = 1U << 28U, <span class="comment">//!< On Windows, create any new handles with OVERLAPPED semantics</span></div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">byte_lock_insanity</a> = 1U << 29U, <span class="comment">//!< Using insane POSIX byte range locks</span></div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">anonymous_inode</a> = 1U << 30U <span class="comment">//!< This is an inode created with no representation on the filing system</span></div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span> <span class="comment"></span> }</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">llfio_v2_xxx::handle::anonymous_inode</a></div><div class="ttdoc">This is an inode created with no representation on the filing system. </div><div class="ttdef"><b>Definition:</b> handle.hpp:169</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">llfio_v2_xxx::handle::disable_safety_unlinks</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:137</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">llfio_v2_xxx::handle::none</a></div><div class="ttdoc">No flags. </div><div class="ttdef"><b>Definition:</b> handle.hpp:99</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">llfio_v2_xxx::handle::maximum_prefetching</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:145</div></div> @@ -666,8 +666,8 @@ For portability, you can only assume that barriers write order for a single hand </table> </div><div class="memdoc"> <p>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.</p> -<p>If AFIO 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, AFIO 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 <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> -<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in AFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call AFIO appropriately.</p> +<p>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 <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> +<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in LLFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call LLFIO appropriately.</p> <dl class="section warning"><dt>Warning</dt><dd>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 <b>can change randomly at any moment</b>. Most code written to use absolute file systems paths is <b>racy</b>, so don't do it, use <code>path_handle</code> to fix a base location on the file system and work from that anchor instead!</dd></dl> <dl class="section user"><dt>Memory Allocations</dt><dd>At least one malloc for the <code>path_type</code>, likely several more. </dd></dl> <dl class="section see"><dt>See also</dt><dd><code>algorithm::cached_parent_handle_adapter<T></code> 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. </dd></dl> diff --git a/classllfio__v2__xxx_1_1handle.html b/classllfio__v2__xxx_1_1handle.html index 41e1f363..e5e46a70 100644 --- a/classllfio__v2__xxx_1_1handle.html +++ b/classllfio__v2__xxx_1_1handle.html @@ -346,9 +346,9 @@ std::ostream & </td><td class="memItemRight" valign="bottom"><b>operato </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa334c4a4c42fdb79d7ebc3e73b517e6f8"></a>none </td><td class="fielddoc"><p>No caching whatsoever, all reads and writes come from storage (i.e. <code>O_DIRECT|O_SYNC</code>). Align all i/o to 4Kb boundaries for this to work. <code>flag_disable_safety_fsyncs</code> can be used here. </p> </td></tr> -<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962"></a>unlink_on_first_close </td><td class="fielddoc"><p>Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed to by <code>path()</code> upon the call of <code>close()</code> 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 <code>errc::resource_unavailable_try_again</code> error return. Because this is confusing, unless the <code>win_disable_unlink_emulation</code> flag is also specified, this POSIX behaviour is somewhat emulated by AFIO on older Windows by renaming the file to a random name on <code>close()</code> causing it to appear to have been unlinked immediately. </p> +<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962"></a>unlink_on_first_close </td><td class="fielddoc"><p>Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed to by <code>path()</code> upon the call of <code>close()</code> 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 <code>errc::resource_unavailable_try_again</code> error return. Because this is confusing, unless the <code>win_disable_unlink_emulation</code> flag is also specified, this POSIX behaviour is somewhat emulated by LLFIO on older Windows by renaming the file to a random name on <code>close()</code> causing it to appear to have been unlinked immediately. </p> </td></tr> -<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9"></a>disable_safety_fsyncs </td><td class="fielddoc"><p>Some kernel caching modes have unhelpfully inconsistent behaviours in getting your data onto storage, so by default unless this flag is specified AFIO 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.</p> +<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9"></a>disable_safety_fsyncs </td><td class="fielddoc"><p>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.</p> <p>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.</p> <p>This only occurs for these kernel caching modes: caching::none caching::reads caching::reads_and_metadata caching::safety_fsyncs </p> </td></tr> @@ -362,7 +362,7 @@ std::ostream & </td><td class="memItemRight" valign="bottom"><b>operato </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0"></a>win_disable_sparse_file_creation </td><td class="fielddoc"><p>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.</p> <p>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.</p> -<p>As extents-based storage is nearly cost free on NTFS, AFIO 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. </p> +<p>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. </p> </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a"></a>overlapped </td><td class="fielddoc"><p>On Windows, create any new handles with OVERLAPPED semantics. </p> </td></tr> @@ -371,7 +371,7 @@ std::ostream & </td><td class="memItemRight" valign="bottom"><b>operato <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"></a>anonymous_inode </td><td class="fielddoc"><p>This is an inode created with no representation on the filing system. </p> </td></tr> </table> -<div class="fragment"><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>  {</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a> = 0, <span class="comment">//!< No flags</span></div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span> <span class="comment"></span><span class="comment"> /*! Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed</span></div><div class="line"><a name="l00101"></a><span class="lineno"> 101</span> <span class="comment"> to by `path()` upon the call of `close()` if and only if the inode matches. On Windows,</span></div><div class="line"><a name="l00102"></a><span class="lineno"> 102</span> <span class="comment"> if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous</span></div><div class="line"><a name="l00103"></a><span class="lineno"> 103</span> <span class="comment"> editions of Windows, the file entry does not disappears but becomes unavailable for</span></div><div class="line"><a name="l00104"></a><span class="lineno"> 104</span> <span class="comment"> anyone else to open with an `errc::resource_unavailable_try_again` error return. Because this is confusing, unless the</span></div><div class="line"><a name="l00105"></a><span class="lineno"> 105</span> <span class="comment"> `win_disable_unlink_emulation` flag is also specified, this POSIX behaviour is</span></div><div class="line"><a name="l00106"></a><span class="lineno"> 106</span> <span class="comment"> somewhat emulated by AFIO on older Windows by renaming the file to a random name on `close()`</span></div><div class="line"><a name="l00107"></a><span class="lineno"> 107</span> <span class="comment"> causing it to appear to have been unlinked immediately.</span></div><div class="line"><a name="l00108"></a><span class="lineno"> 108</span> <span class="comment"> */</span></div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">unlink_on_first_close</a> = 1U << 0U,</div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span> <span class="comment"></span></div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span> <span class="comment"> /*! Some kernel caching modes have unhelpfully inconsistent behaviours</span></div><div class="line"><a name="l00112"></a><span class="lineno"> 112</span> <span class="comment"> in getting your data onto storage, so by default unless this flag is</span></div><div class="line"><a name="l00113"></a><span class="lineno"> 113</span> <span class="comment"> specified AFIO adds extra fsyncs to the following operations for the</span></div><div class="line"><a name="l00114"></a><span class="lineno"> 114</span> <span class="comment"> caching modes specified below:</span></div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span> <span class="comment"> * truncation of file length either explicitly or during file open.</span></div><div class="line"><a name="l00116"></a><span class="lineno"> 116</span> <span class="comment"> * closing of the handle either explicitly or in the destructor.</span></div><div class="line"><a name="l00117"></a><span class="lineno"> 117</span> <span class="comment"></span></div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span> <span class="comment"> Additionally on Linux only to prevent loss of file metadata:</span></div><div class="line"><a name="l00119"></a><span class="lineno"> 119</span> <span class="comment"> * On the parent directory whenever a file might have been created.</span></div><div class="line"><a name="l00120"></a><span class="lineno"> 120</span> <span class="comment"> * On the parent directory on file close.</span></div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span> <span class="comment"></span></div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span> <span class="comment"> This only occurs for these kernel caching modes:</span></div><div class="line"><a name="l00123"></a><span class="lineno"> 123</span> <span class="comment"> * caching::none</span></div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span> <span class="comment"> * caching::reads</span></div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span> <span class="comment"> * caching::reads_and_metadata</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> <span class="comment"> * caching::safety_fsyncs</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> <span class="comment"> */</span></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9">disable_safety_fsyncs</a> = 1U << 2U,<span class="comment"></span></div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span> <span class="comment"> /*! `file_handle::unlink()` could accidentally delete the wrong file if someone has</span></div><div class="line"><a name="l00130"></a><span class="lineno"> 130</span> <span class="comment"> renamed the open file handle since the time it was opened. To prevent this occuring,</span></div><div class="line"><a name="l00131"></a><span class="lineno"> 131</span> <span class="comment"> where the OS doesn't provide race free unlink-by-open-handle we compare the inode of</span></div><div class="line"><a name="l00132"></a><span class="lineno"> 132</span> <span class="comment"> the path we are about to unlink with that of the open handle before unlinking.</span></div><div class="line"><a name="l00133"></a><span class="lineno"> 133</span> <span class="comment"> \warning This does not prevent races where in between the time of checking the inode</span></div><div class="line"><a name="l00134"></a><span class="lineno"> 134</span> <span class="comment"> and executing the unlink a third party changes the item about to be unlinked. Only</span></div><div class="line"><a name="l00135"></a><span class="lineno"> 135</span> <span class="comment"> operating systems with a true race-free unlink syscall are race free.</span></div><div class="line"><a name="l00136"></a><span class="lineno"> 136</span> <span class="comment"> */</span></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">disable_safety_unlinks</a> = 1U << 3U,<span class="comment"></span></div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span> <span class="comment"> /*! Ask the OS to disable prefetching of data. This can improve random</span></div><div class="line"><a name="l00139"></a><span class="lineno"> 139</span> <span class="comment"> i/o performance.</span></div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span> <span class="comment"> */</span></div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">disable_prefetching</a> = 1U << 4U,<span class="comment"></span></div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span> <span class="comment"> /*! Ask the OS to maximise prefetching of data, possibly prefetching the entire file</span></div><div class="line"><a name="l00143"></a><span class="lineno"> 143</span> <span class="comment"> into kernel cache. This can improve sequential i/o performance.</span></div><div class="line"><a name="l00144"></a><span class="lineno"> 144</span> <span class="comment"> */</span></div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">maximum_prefetching</a> = 1U << 5U,</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span> </div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">win_disable_unlink_emulation</a> = 1U << 24U, <span class="comment">//!< See the documentation for `unlink_on_first_close`</span></div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span> <span class="comment"></span><span class="comment"> /*! Microsoft Windows NTFS, having been created in the late 1980s, did not originally</span></div><div class="line"><a name="l00149"></a><span class="lineno"> 149</span> <span class="comment"> implement extents-based storage and thus could only represent sparse files via</span></div><div class="line"><a name="l00150"></a><span class="lineno"> 150</span> <span class="comment"> efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000),</span></div><div class="line"><a name="l00151"></a><span class="lineno"> 151</span> <span class="comment"> a proper extents-based on-storage representation was added, thus allowing only 64Kb</span></div><div class="line"><a name="l00152"></a><span class="lineno"> 152</span> <span class="comment"> extent chunks written to be stored irrespective of whatever the maximum file extent</span></div><div class="line"><a name="l00153"></a><span class="lineno"> 153</span> <span class="comment"> was set to.</span></div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span> <span class="comment"></span></div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span> <span class="comment"> For various historical reasons, extents-based storage is disabled by default in newly</span></div><div class="line"><a name="l00156"></a><span class="lineno"> 156</span> <span class="comment"> created files on NTFS, unlike in almost every other major filing system. You have to</span></div><div class="line"><a name="l00157"></a><span class="lineno"> 157</span> <span class="comment"> explicitly "opt in" to extents-based storage.</span></div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span> <span class="comment"></span></div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span> <span class="comment"> As extents-based storage is nearly cost free on NTFS, AFIO by default opts in to</span></div><div class="line"><a name="l00160"></a><span class="lineno"> 160</span> <span class="comment"> extents-based storage for any empty file it creates. If you don't want this, you</span></div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span> <span class="comment"> can specify this flag to prevent that happening.</span></div><div class="line"><a name="l00162"></a><span class="lineno"> 162</span> <span class="comment"> */</span></div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">win_disable_sparse_file_creation</a> = 1U << 25U,</div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span> </div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span>  <span class="comment">// NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!</span></div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span> </div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">overlapped</a> = 1U << 28U, <span class="comment">//!< On Windows, create any new handles with OVERLAPPED semantics</span></div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">byte_lock_insanity</a> = 1U << 29U, <span class="comment">//!< Using insane POSIX byte range locks</span></div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">anonymous_inode</a> = 1U << 30U <span class="comment">//!< This is an inode created with no representation on the filing system</span></div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span> <span class="comment"></span> }</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">llfio_v2_xxx::handle::anonymous_inode</a></div><div class="ttdoc">This is an inode created with no representation on the filing system. </div><div class="ttdef"><b>Definition:</b> handle.hpp:169</div></div> +<div class="fragment"><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>  {</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a> = 0, <span class="comment">//!< No flags</span></div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span> <span class="comment"></span><span class="comment"> /*! Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed</span></div><div class="line"><a name="l00101"></a><span class="lineno"> 101</span> <span class="comment"> to by `path()` upon the call of `close()` if and only if the inode matches. On Windows,</span></div><div class="line"><a name="l00102"></a><span class="lineno"> 102</span> <span class="comment"> if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous</span></div><div class="line"><a name="l00103"></a><span class="lineno"> 103</span> <span class="comment"> editions of Windows, the file entry does not disappears but becomes unavailable for</span></div><div class="line"><a name="l00104"></a><span class="lineno"> 104</span> <span class="comment"> anyone else to open with an `errc::resource_unavailable_try_again` error return. Because this is confusing, unless the</span></div><div class="line"><a name="l00105"></a><span class="lineno"> 105</span> <span class="comment"> `win_disable_unlink_emulation` flag is also specified, this POSIX behaviour is</span></div><div class="line"><a name="l00106"></a><span class="lineno"> 106</span> <span class="comment"> somewhat emulated by LLFIO on older Windows by renaming the file to a random name on `close()`</span></div><div class="line"><a name="l00107"></a><span class="lineno"> 107</span> <span class="comment"> causing it to appear to have been unlinked immediately.</span></div><div class="line"><a name="l00108"></a><span class="lineno"> 108</span> <span class="comment"> */</span></div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">unlink_on_first_close</a> = 1U << 0U,</div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span> <span class="comment"></span></div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span> <span class="comment"> /*! Some kernel caching modes have unhelpfully inconsistent behaviours</span></div><div class="line"><a name="l00112"></a><span class="lineno"> 112</span> <span class="comment"> in getting your data onto storage, so by default unless this flag is</span></div><div class="line"><a name="l00113"></a><span class="lineno"> 113</span> <span class="comment"> specified LLFIO adds extra fsyncs to the following operations for the</span></div><div class="line"><a name="l00114"></a><span class="lineno"> 114</span> <span class="comment"> caching modes specified below:</span></div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span> <span class="comment"> * truncation of file length either explicitly or during file open.</span></div><div class="line"><a name="l00116"></a><span class="lineno"> 116</span> <span class="comment"> * closing of the handle either explicitly or in the destructor.</span></div><div class="line"><a name="l00117"></a><span class="lineno"> 117</span> <span class="comment"></span></div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span> <span class="comment"> Additionally on Linux only to prevent loss of file metadata:</span></div><div class="line"><a name="l00119"></a><span class="lineno"> 119</span> <span class="comment"> * On the parent directory whenever a file might have been created.</span></div><div class="line"><a name="l00120"></a><span class="lineno"> 120</span> <span class="comment"> * On the parent directory on file close.</span></div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span> <span class="comment"></span></div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span> <span class="comment"> This only occurs for these kernel caching modes:</span></div><div class="line"><a name="l00123"></a><span class="lineno"> 123</span> <span class="comment"> * caching::none</span></div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span> <span class="comment"> * caching::reads</span></div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span> <span class="comment"> * caching::reads_and_metadata</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> <span class="comment"> * caching::safety_fsyncs</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> <span class="comment"> */</span></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9">disable_safety_fsyncs</a> = 1U << 2U,<span class="comment"></span></div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span> <span class="comment"> /*! `file_handle::unlink()` could accidentally delete the wrong file if someone has</span></div><div class="line"><a name="l00130"></a><span class="lineno"> 130</span> <span class="comment"> renamed the open file handle since the time it was opened. To prevent this occuring,</span></div><div class="line"><a name="l00131"></a><span class="lineno"> 131</span> <span class="comment"> where the OS doesn't provide race free unlink-by-open-handle we compare the inode of</span></div><div class="line"><a name="l00132"></a><span class="lineno"> 132</span> <span class="comment"> the path we are about to unlink with that of the open handle before unlinking.</span></div><div class="line"><a name="l00133"></a><span class="lineno"> 133</span> <span class="comment"> \warning This does not prevent races where in between the time of checking the inode</span></div><div class="line"><a name="l00134"></a><span class="lineno"> 134</span> <span class="comment"> and executing the unlink a third party changes the item about to be unlinked. Only</span></div><div class="line"><a name="l00135"></a><span class="lineno"> 135</span> <span class="comment"> operating systems with a true race-free unlink syscall are race free.</span></div><div class="line"><a name="l00136"></a><span class="lineno"> 136</span> <span class="comment"> */</span></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">disable_safety_unlinks</a> = 1U << 3U,<span class="comment"></span></div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span> <span class="comment"> /*! Ask the OS to disable prefetching of data. This can improve random</span></div><div class="line"><a name="l00139"></a><span class="lineno"> 139</span> <span class="comment"> i/o performance.</span></div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span> <span class="comment"> */</span></div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">disable_prefetching</a> = 1U << 4U,<span class="comment"></span></div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span> <span class="comment"> /*! Ask the OS to maximise prefetching of data, possibly prefetching the entire file</span></div><div class="line"><a name="l00143"></a><span class="lineno"> 143</span> <span class="comment"> into kernel cache. This can improve sequential i/o performance.</span></div><div class="line"><a name="l00144"></a><span class="lineno"> 144</span> <span class="comment"> */</span></div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">maximum_prefetching</a> = 1U << 5U,</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span> </div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">win_disable_unlink_emulation</a> = 1U << 24U, <span class="comment">//!< See the documentation for `unlink_on_first_close`</span></div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span> <span class="comment"></span><span class="comment"> /*! Microsoft Windows NTFS, having been created in the late 1980s, did not originally</span></div><div class="line"><a name="l00149"></a><span class="lineno"> 149</span> <span class="comment"> implement extents-based storage and thus could only represent sparse files via</span></div><div class="line"><a name="l00150"></a><span class="lineno"> 150</span> <span class="comment"> efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000),</span></div><div class="line"><a name="l00151"></a><span class="lineno"> 151</span> <span class="comment"> a proper extents-based on-storage representation was added, thus allowing only 64Kb</span></div><div class="line"><a name="l00152"></a><span class="lineno"> 152</span> <span class="comment"> extent chunks written to be stored irrespective of whatever the maximum file extent</span></div><div class="line"><a name="l00153"></a><span class="lineno"> 153</span> <span class="comment"> was set to.</span></div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span> <span class="comment"></span></div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span> <span class="comment"> For various historical reasons, extents-based storage is disabled by default in newly</span></div><div class="line"><a name="l00156"></a><span class="lineno"> 156</span> <span class="comment"> created files on NTFS, unlike in almost every other major filing system. You have to</span></div><div class="line"><a name="l00157"></a><span class="lineno"> 157</span> <span class="comment"> explicitly "opt in" to extents-based storage.</span></div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span> <span class="comment"></span></div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span> <span class="comment"> As extents-based storage is nearly cost free on NTFS, LLFIO by default opts in to</span></div><div class="line"><a name="l00160"></a><span class="lineno"> 160</span> <span class="comment"> extents-based storage for any empty file it creates. If you don't want this, you</span></div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span> <span class="comment"> can specify this flag to prevent that happening.</span></div><div class="line"><a name="l00162"></a><span class="lineno"> 162</span> <span class="comment"> */</span></div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">win_disable_sparse_file_creation</a> = 1U << 25U,</div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span> </div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span>  <span class="comment">// NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!</span></div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span> </div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">overlapped</a> = 1U << 28U, <span class="comment">//!< On Windows, create any new handles with OVERLAPPED semantics</span></div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">byte_lock_insanity</a> = 1U << 29U, <span class="comment">//!< Using insane POSIX byte range locks</span></div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">anonymous_inode</a> = 1U << 30U <span class="comment">//!< This is an inode created with no representation on the filing system</span></div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span> <span class="comment"></span> }</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">llfio_v2_xxx::handle::anonymous_inode</a></div><div class="ttdoc">This is an inode created with no representation on the filing system. </div><div class="ttdef"><b>Definition:</b> handle.hpp:169</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">llfio_v2_xxx::handle::disable_safety_unlinks</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:137</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">llfio_v2_xxx::handle::none</a></div><div class="ttdoc">No flags. </div><div class="ttdef"><b>Definition:</b> handle.hpp:99</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">llfio_v2_xxx::handle::maximum_prefetching</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:145</div></div> @@ -547,8 +547,8 @@ std::ostream & </td><td class="memItemRight" valign="bottom"><b>operato </table> </div><div class="memdoc"> <p>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.</p> -<p>If AFIO 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, AFIO 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 <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> -<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in AFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call AFIO appropriately.</p> +<p>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 <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> +<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in LLFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call LLFIO appropriately.</p> <dl class="section warning"><dt>Warning</dt><dd>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 <b>can change randomly at any moment</b>. Most code written to use absolute file systems paths is <b>racy</b>, so don't do it, use <code>path_handle</code> to fix a base location on the file system and work from that anchor instead!</dd></dl> <dl class="section user"><dt>Memory Allocations</dt><dd>At least one malloc for the <code>path_type</code>, likely several more. </dd></dl> <dl class="section see"><dt>See also</dt><dd><code>algorithm::cached_parent_handle_adapter<T></code> 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. </dd></dl> diff --git a/classllfio__v2__xxx_1_1io__handle.html b/classllfio__v2__xxx_1_1io__handle.html index 07c0db5d..1e0712e6 100644 --- a/classllfio__v2__xxx_1_1io__handle.html +++ b/classllfio__v2__xxx_1_1io__handle.html @@ -374,9 +374,9 @@ flag </td><td class="memItemRight" valign="bottom"><b>_flags</b> {flag::non </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa334c4a4c42fdb79d7ebc3e73b517e6f8"></a>none </td><td class="fielddoc"><p>No caching whatsoever, all reads and writes come from storage (i.e. <code>O_DIRECT|O_SYNC</code>). Align all i/o to 4Kb boundaries for this to work. <code>flag_disable_safety_fsyncs</code> can be used here. </p> </td></tr> -<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962"></a>unlink_on_first_close </td><td class="fielddoc"><p>Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed to by <code>path()</code> upon the call of <code>close()</code> 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 <code>errc::resource_unavailable_try_again</code> error return. Because this is confusing, unless the <code>win_disable_unlink_emulation</code> flag is also specified, this POSIX behaviour is somewhat emulated by AFIO on older Windows by renaming the file to a random name on <code>close()</code> causing it to appear to have been unlinked immediately. </p> +<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962"></a>unlink_on_first_close </td><td class="fielddoc"><p>Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed to by <code>path()</code> upon the call of <code>close()</code> 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 <code>errc::resource_unavailable_try_again</code> error return. Because this is confusing, unless the <code>win_disable_unlink_emulation</code> flag is also specified, this POSIX behaviour is somewhat emulated by LLFIO on older Windows by renaming the file to a random name on <code>close()</code> causing it to appear to have been unlinked immediately. </p> </td></tr> -<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9"></a>disable_safety_fsyncs </td><td class="fielddoc"><p>Some kernel caching modes have unhelpfully inconsistent behaviours in getting your data onto storage, so by default unless this flag is specified AFIO 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.</p> +<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9"></a>disable_safety_fsyncs </td><td class="fielddoc"><p>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.</p> <p>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.</p> <p>This only occurs for these kernel caching modes: caching::none caching::reads caching::reads_and_metadata caching::safety_fsyncs </p> </td></tr> @@ -390,7 +390,7 @@ flag </td><td class="memItemRight" valign="bottom"><b>_flags</b> {flag::non </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0"></a>win_disable_sparse_file_creation </td><td class="fielddoc"><p>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.</p> <p>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.</p> -<p>As extents-based storage is nearly cost free on NTFS, AFIO 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. </p> +<p>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. </p> </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a"></a>overlapped </td><td class="fielddoc"><p>On Windows, create any new handles with OVERLAPPED semantics. </p> </td></tr> @@ -399,7 +399,7 @@ flag </td><td class="memItemRight" valign="bottom"><b>_flags</b> {flag::non <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"></a>anonymous_inode </td><td class="fielddoc"><p>This is an inode created with no representation on the filing system. </p> </td></tr> </table> -<div class="fragment"><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>  {</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a> = 0, <span class="comment">//!< No flags</span></div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span> <span class="comment"></span><span class="comment"> /*! Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed</span></div><div class="line"><a name="l00101"></a><span class="lineno"> 101</span> <span class="comment"> to by `path()` upon the call of `close()` if and only if the inode matches. On Windows,</span></div><div class="line"><a name="l00102"></a><span class="lineno"> 102</span> <span class="comment"> if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous</span></div><div class="line"><a name="l00103"></a><span class="lineno"> 103</span> <span class="comment"> editions of Windows, the file entry does not disappears but becomes unavailable for</span></div><div class="line"><a name="l00104"></a><span class="lineno"> 104</span> <span class="comment"> anyone else to open with an `errc::resource_unavailable_try_again` error return. Because this is confusing, unless the</span></div><div class="line"><a name="l00105"></a><span class="lineno"> 105</span> <span class="comment"> `win_disable_unlink_emulation` flag is also specified, this POSIX behaviour is</span></div><div class="line"><a name="l00106"></a><span class="lineno"> 106</span> <span class="comment"> somewhat emulated by AFIO on older Windows by renaming the file to a random name on `close()`</span></div><div class="line"><a name="l00107"></a><span class="lineno"> 107</span> <span class="comment"> causing it to appear to have been unlinked immediately.</span></div><div class="line"><a name="l00108"></a><span class="lineno"> 108</span> <span class="comment"> */</span></div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">unlink_on_first_close</a> = 1U << 0U,</div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span> <span class="comment"></span></div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span> <span class="comment"> /*! Some kernel caching modes have unhelpfully inconsistent behaviours</span></div><div class="line"><a name="l00112"></a><span class="lineno"> 112</span> <span class="comment"> in getting your data onto storage, so by default unless this flag is</span></div><div class="line"><a name="l00113"></a><span class="lineno"> 113</span> <span class="comment"> specified AFIO adds extra fsyncs to the following operations for the</span></div><div class="line"><a name="l00114"></a><span class="lineno"> 114</span> <span class="comment"> caching modes specified below:</span></div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span> <span class="comment"> * truncation of file length either explicitly or during file open.</span></div><div class="line"><a name="l00116"></a><span class="lineno"> 116</span> <span class="comment"> * closing of the handle either explicitly or in the destructor.</span></div><div class="line"><a name="l00117"></a><span class="lineno"> 117</span> <span class="comment"></span></div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span> <span class="comment"> Additionally on Linux only to prevent loss of file metadata:</span></div><div class="line"><a name="l00119"></a><span class="lineno"> 119</span> <span class="comment"> * On the parent directory whenever a file might have been created.</span></div><div class="line"><a name="l00120"></a><span class="lineno"> 120</span> <span class="comment"> * On the parent directory on file close.</span></div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span> <span class="comment"></span></div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span> <span class="comment"> This only occurs for these kernel caching modes:</span></div><div class="line"><a name="l00123"></a><span class="lineno"> 123</span> <span class="comment"> * caching::none</span></div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span> <span class="comment"> * caching::reads</span></div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span> <span class="comment"> * caching::reads_and_metadata</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> <span class="comment"> * caching::safety_fsyncs</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> <span class="comment"> */</span></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9">disable_safety_fsyncs</a> = 1U << 2U,<span class="comment"></span></div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span> <span class="comment"> /*! `file_handle::unlink()` could accidentally delete the wrong file if someone has</span></div><div class="line"><a name="l00130"></a><span class="lineno"> 130</span> <span class="comment"> renamed the open file handle since the time it was opened. To prevent this occuring,</span></div><div class="line"><a name="l00131"></a><span class="lineno"> 131</span> <span class="comment"> where the OS doesn't provide race free unlink-by-open-handle we compare the inode of</span></div><div class="line"><a name="l00132"></a><span class="lineno"> 132</span> <span class="comment"> the path we are about to unlink with that of the open handle before unlinking.</span></div><div class="line"><a name="l00133"></a><span class="lineno"> 133</span> <span class="comment"> \warning This does not prevent races where in between the time of checking the inode</span></div><div class="line"><a name="l00134"></a><span class="lineno"> 134</span> <span class="comment"> and executing the unlink a third party changes the item about to be unlinked. Only</span></div><div class="line"><a name="l00135"></a><span class="lineno"> 135</span> <span class="comment"> operating systems with a true race-free unlink syscall are race free.</span></div><div class="line"><a name="l00136"></a><span class="lineno"> 136</span> <span class="comment"> */</span></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">disable_safety_unlinks</a> = 1U << 3U,<span class="comment"></span></div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span> <span class="comment"> /*! Ask the OS to disable prefetching of data. This can improve random</span></div><div class="line"><a name="l00139"></a><span class="lineno"> 139</span> <span class="comment"> i/o performance.</span></div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span> <span class="comment"> */</span></div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">disable_prefetching</a> = 1U << 4U,<span class="comment"></span></div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span> <span class="comment"> /*! Ask the OS to maximise prefetching of data, possibly prefetching the entire file</span></div><div class="line"><a name="l00143"></a><span class="lineno"> 143</span> <span class="comment"> into kernel cache. This can improve sequential i/o performance.</span></div><div class="line"><a name="l00144"></a><span class="lineno"> 144</span> <span class="comment"> */</span></div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">maximum_prefetching</a> = 1U << 5U,</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span> </div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">win_disable_unlink_emulation</a> = 1U << 24U, <span class="comment">//!< See the documentation for `unlink_on_first_close`</span></div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span> <span class="comment"></span><span class="comment"> /*! Microsoft Windows NTFS, having been created in the late 1980s, did not originally</span></div><div class="line"><a name="l00149"></a><span class="lineno"> 149</span> <span class="comment"> implement extents-based storage and thus could only represent sparse files via</span></div><div class="line"><a name="l00150"></a><span class="lineno"> 150</span> <span class="comment"> efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000),</span></div><div class="line"><a name="l00151"></a><span class="lineno"> 151</span> <span class="comment"> a proper extents-based on-storage representation was added, thus allowing only 64Kb</span></div><div class="line"><a name="l00152"></a><span class="lineno"> 152</span> <span class="comment"> extent chunks written to be stored irrespective of whatever the maximum file extent</span></div><div class="line"><a name="l00153"></a><span class="lineno"> 153</span> <span class="comment"> was set to.</span></div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span> <span class="comment"></span></div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span> <span class="comment"> For various historical reasons, extents-based storage is disabled by default in newly</span></div><div class="line"><a name="l00156"></a><span class="lineno"> 156</span> <span class="comment"> created files on NTFS, unlike in almost every other major filing system. You have to</span></div><div class="line"><a name="l00157"></a><span class="lineno"> 157</span> <span class="comment"> explicitly "opt in" to extents-based storage.</span></div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span> <span class="comment"></span></div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span> <span class="comment"> As extents-based storage is nearly cost free on NTFS, AFIO by default opts in to</span></div><div class="line"><a name="l00160"></a><span class="lineno"> 160</span> <span class="comment"> extents-based storage for any empty file it creates. If you don't want this, you</span></div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span> <span class="comment"> can specify this flag to prevent that happening.</span></div><div class="line"><a name="l00162"></a><span class="lineno"> 162</span> <span class="comment"> */</span></div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">win_disable_sparse_file_creation</a> = 1U << 25U,</div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span> </div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span>  <span class="comment">// NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!</span></div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span> </div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">overlapped</a> = 1U << 28U, <span class="comment">//!< On Windows, create any new handles with OVERLAPPED semantics</span></div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">byte_lock_insanity</a> = 1U << 29U, <span class="comment">//!< Using insane POSIX byte range locks</span></div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">anonymous_inode</a> = 1U << 30U <span class="comment">//!< This is an inode created with no representation on the filing system</span></div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span> <span class="comment"></span> }</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">llfio_v2_xxx::handle::anonymous_inode</a></div><div class="ttdoc">This is an inode created with no representation on the filing system. </div><div class="ttdef"><b>Definition:</b> handle.hpp:169</div></div> +<div class="fragment"><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>  {</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a> = 0, <span class="comment">//!< No flags</span></div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span> <span class="comment"></span><span class="comment"> /*! Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed</span></div><div class="line"><a name="l00101"></a><span class="lineno"> 101</span> <span class="comment"> to by `path()` upon the call of `close()` if and only if the inode matches. On Windows,</span></div><div class="line"><a name="l00102"></a><span class="lineno"> 102</span> <span class="comment"> if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous</span></div><div class="line"><a name="l00103"></a><span class="lineno"> 103</span> <span class="comment"> editions of Windows, the file entry does not disappears but becomes unavailable for</span></div><div class="line"><a name="l00104"></a><span class="lineno"> 104</span> <span class="comment"> anyone else to open with an `errc::resource_unavailable_try_again` error return. Because this is confusing, unless the</span></div><div class="line"><a name="l00105"></a><span class="lineno"> 105</span> <span class="comment"> `win_disable_unlink_emulation` flag is also specified, this POSIX behaviour is</span></div><div class="line"><a name="l00106"></a><span class="lineno"> 106</span> <span class="comment"> somewhat emulated by LLFIO on older Windows by renaming the file to a random name on `close()`</span></div><div class="line"><a name="l00107"></a><span class="lineno"> 107</span> <span class="comment"> causing it to appear to have been unlinked immediately.</span></div><div class="line"><a name="l00108"></a><span class="lineno"> 108</span> <span class="comment"> */</span></div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">unlink_on_first_close</a> = 1U << 0U,</div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span> <span class="comment"></span></div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span> <span class="comment"> /*! Some kernel caching modes have unhelpfully inconsistent behaviours</span></div><div class="line"><a name="l00112"></a><span class="lineno"> 112</span> <span class="comment"> in getting your data onto storage, so by default unless this flag is</span></div><div class="line"><a name="l00113"></a><span class="lineno"> 113</span> <span class="comment"> specified LLFIO adds extra fsyncs to the following operations for the</span></div><div class="line"><a name="l00114"></a><span class="lineno"> 114</span> <span class="comment"> caching modes specified below:</span></div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span> <span class="comment"> * truncation of file length either explicitly or during file open.</span></div><div class="line"><a name="l00116"></a><span class="lineno"> 116</span> <span class="comment"> * closing of the handle either explicitly or in the destructor.</span></div><div class="line"><a name="l00117"></a><span class="lineno"> 117</span> <span class="comment"></span></div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span> <span class="comment"> Additionally on Linux only to prevent loss of file metadata:</span></div><div class="line"><a name="l00119"></a><span class="lineno"> 119</span> <span class="comment"> * On the parent directory whenever a file might have been created.</span></div><div class="line"><a name="l00120"></a><span class="lineno"> 120</span> <span class="comment"> * On the parent directory on file close.</span></div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span> <span class="comment"></span></div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span> <span class="comment"> This only occurs for these kernel caching modes:</span></div><div class="line"><a name="l00123"></a><span class="lineno"> 123</span> <span class="comment"> * caching::none</span></div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span> <span class="comment"> * caching::reads</span></div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span> <span class="comment"> * caching::reads_and_metadata</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> <span class="comment"> * caching::safety_fsyncs</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> <span class="comment"> */</span></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9">disable_safety_fsyncs</a> = 1U << 2U,<span class="comment"></span></div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span> <span class="comment"> /*! `file_handle::unlink()` could accidentally delete the wrong file if someone has</span></div><div class="line"><a name="l00130"></a><span class="lineno"> 130</span> <span class="comment"> renamed the open file handle since the time it was opened. To prevent this occuring,</span></div><div class="line"><a name="l00131"></a><span class="lineno"> 131</span> <span class="comment"> where the OS doesn't provide race free unlink-by-open-handle we compare the inode of</span></div><div class="line"><a name="l00132"></a><span class="lineno"> 132</span> <span class="comment"> the path we are about to unlink with that of the open handle before unlinking.</span></div><div class="line"><a name="l00133"></a><span class="lineno"> 133</span> <span class="comment"> \warning This does not prevent races where in between the time of checking the inode</span></div><div class="line"><a name="l00134"></a><span class="lineno"> 134</span> <span class="comment"> and executing the unlink a third party changes the item about to be unlinked. Only</span></div><div class="line"><a name="l00135"></a><span class="lineno"> 135</span> <span class="comment"> operating systems with a true race-free unlink syscall are race free.</span></div><div class="line"><a name="l00136"></a><span class="lineno"> 136</span> <span class="comment"> */</span></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">disable_safety_unlinks</a> = 1U << 3U,<span class="comment"></span></div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span> <span class="comment"> /*! Ask the OS to disable prefetching of data. This can improve random</span></div><div class="line"><a name="l00139"></a><span class="lineno"> 139</span> <span class="comment"> i/o performance.</span></div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span> <span class="comment"> */</span></div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">disable_prefetching</a> = 1U << 4U,<span class="comment"></span></div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span> <span class="comment"> /*! Ask the OS to maximise prefetching of data, possibly prefetching the entire file</span></div><div class="line"><a name="l00143"></a><span class="lineno"> 143</span> <span class="comment"> into kernel cache. This can improve sequential i/o performance.</span></div><div class="line"><a name="l00144"></a><span class="lineno"> 144</span> <span class="comment"> */</span></div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">maximum_prefetching</a> = 1U << 5U,</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span> </div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">win_disable_unlink_emulation</a> = 1U << 24U, <span class="comment">//!< See the documentation for `unlink_on_first_close`</span></div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span> <span class="comment"></span><span class="comment"> /*! Microsoft Windows NTFS, having been created in the late 1980s, did not originally</span></div><div class="line"><a name="l00149"></a><span class="lineno"> 149</span> <span class="comment"> implement extents-based storage and thus could only represent sparse files via</span></div><div class="line"><a name="l00150"></a><span class="lineno"> 150</span> <span class="comment"> efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000),</span></div><div class="line"><a name="l00151"></a><span class="lineno"> 151</span> <span class="comment"> a proper extents-based on-storage representation was added, thus allowing only 64Kb</span></div><div class="line"><a name="l00152"></a><span class="lineno"> 152</span> <span class="comment"> extent chunks written to be stored irrespective of whatever the maximum file extent</span></div><div class="line"><a name="l00153"></a><span class="lineno"> 153</span> <span class="comment"> was set to.</span></div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span> <span class="comment"></span></div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span> <span class="comment"> For various historical reasons, extents-based storage is disabled by default in newly</span></div><div class="line"><a name="l00156"></a><span class="lineno"> 156</span> <span class="comment"> created files on NTFS, unlike in almost every other major filing system. You have to</span></div><div class="line"><a name="l00157"></a><span class="lineno"> 157</span> <span class="comment"> explicitly "opt in" to extents-based storage.</span></div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span> <span class="comment"></span></div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span> <span class="comment"> As extents-based storage is nearly cost free on NTFS, LLFIO by default opts in to</span></div><div class="line"><a name="l00160"></a><span class="lineno"> 160</span> <span class="comment"> extents-based storage for any empty file it creates. If you don't want this, you</span></div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span> <span class="comment"> can specify this flag to prevent that happening.</span></div><div class="line"><a name="l00162"></a><span class="lineno"> 162</span> <span class="comment"> */</span></div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">win_disable_sparse_file_creation</a> = 1U << 25U,</div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span> </div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span>  <span class="comment">// NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!</span></div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span> </div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">overlapped</a> = 1U << 28U, <span class="comment">//!< On Windows, create any new handles with OVERLAPPED semantics</span></div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">byte_lock_insanity</a> = 1U << 29U, <span class="comment">//!< Using insane POSIX byte range locks</span></div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">anonymous_inode</a> = 1U << 30U <span class="comment">//!< This is an inode created with no representation on the filing system</span></div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span> <span class="comment"></span> }</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">llfio_v2_xxx::handle::anonymous_inode</a></div><div class="ttdoc">This is an inode created with no representation on the filing system. </div><div class="ttdef"><b>Definition:</b> handle.hpp:169</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">llfio_v2_xxx::handle::disable_safety_unlinks</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:137</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">llfio_v2_xxx::handle::none</a></div><div class="ttdoc">No flags. </div><div class="ttdef"><b>Definition:</b> handle.hpp:99</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">llfio_v2_xxx::handle::maximum_prefetching</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:145</div></div> @@ -560,8 +560,8 @@ For portability, you can only assume that barriers write order for a single hand </table> </div><div class="memdoc"> <p>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.</p> -<p>If AFIO 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, AFIO 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 <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> -<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in AFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call AFIO appropriately.</p> +<p>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 <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> +<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in LLFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call LLFIO appropriately.</p> <dl class="section warning"><dt>Warning</dt><dd>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 <b>can change randomly at any moment</b>. Most code written to use absolute file systems paths is <b>racy</b>, so don't do it, use <code>path_handle</code> to fix a base location on the file system and work from that anchor instead!</dd></dl> <dl class="section user"><dt>Memory Allocations</dt><dd>At least one malloc for the <code>path_type</code>, likely several more. </dd></dl> <dl class="section see"><dt>See also</dt><dd><code>algorithm::cached_parent_handle_adapter<T></code> 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. </dd></dl> diff --git a/classllfio__v2__xxx_1_1io__service.html b/classllfio__v2__xxx_1_1io__service.html index 0f6cfacc..f642535e 100644 --- a/classllfio__v2__xxx_1_1io__service.html +++ b/classllfio__v2__xxx_1_1io__service.html @@ -198,7 +198,7 @@ class </td><td class="memItemRight" valign="bottom"><b>async_file_handle</b </table> <a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2> <div class="textblock"><p>An asynchronous i/o multiplexer service. </p> -<p>This service is used in conjunction with <code>async_file_handle</code> to multiplex initating i/o and completing it onto a single kernel thread. Unlike the <code>io_service</code> in ASIO or the Networking TS, this <code>io_service</code> is much simpler, in particular it is single threaded per instance only i.e. you must run a separate <code>io_service</code> instance one per kernel thread if you wish to run i/o processing across multiple threads. AFIO does not do this for you (and for good reason, unlike socket i/o, it is generally unwise to distribute file i/o across kernel threads due to the much more code executable between user space and physical storage i.e. keeping processing per CPU core hot in cache delivers outsize benefits compared to socket i/o).</p> +<p>This service is used in conjunction with <code>async_file_handle</code> to multiplex initating i/o and completing it onto a single kernel thread. Unlike the <code>io_service</code> in ASIO or the Networking TS, this <code>io_service</code> is much simpler, in particular it is single threaded per instance only i.e. you must run a separate <code>io_service</code> instance one per kernel thread if you wish to run i/o processing across multiple threads. LLFIO does not do this for you (and for good reason, unlike socket i/o, it is generally unwise to distribute file i/o across kernel threads due to the much more code executable between user space and physical storage i.e. keeping processing per CPU core hot in cache delivers outsize benefits compared to socket i/o).</p> <p>Furthermore, you cannot use this i/o service in any way from any thread other than where it was created. You cannot call its <code>run()</code> from any thread other than where it was created. And you cannot initiate i/o on an <code>async_file_handle</code> from any thread other than where its owning i/o service was created.</p> <p>In other words, keep your i/o service and all associated file handles on their owning thread. The sole function you can call from another thread is <code>post()</code> which lets you execute some callback in the <code>run()</code> of the owning thread. This lets you schedule i/o from other threads if you really must do that.</p> <div class="fragment"><div class="line"> <span class="keyword">namespace </span>llfio = <a class="code" href="group__config.html#gac9f7f0153adb9034d26c4554728f817a">LLFIO_V2_NAMESPACE</a>;</div><div class="line"></div><div class="line"> <span class="comment">// Create an i/o service for this thread</span></div><div class="line"> llfio::io_service service;</div><div class="line"></div><div class="line"> <span class="comment">// Create an async file i/o handle attached to the i/o service for this thread</span></div><div class="line"> llfio::async_file_handle h = <a class="code" href="async__file__handle_8hpp.html#a2f1958f5d16f237b02599b7222c6d1ba">llfio::async_file_handle::async_file</a>(service, {}, <span class="stringliteral">"temp"</span>, <a class="code" href="namespacellfio__v2__xxx.html#a5a8908704c9988bbecc69c2359e6fd4a">llfio::file_handle::mode::write</a>, llfio::file_handle::creation::if_needed, llfio::file_handle::caching::only_metadata, llfio::file_handle::flag::unlink_on_first_close).value();</div><div class="line"></div><div class="line"> <span class="comment">// Truncate to 1Mb</span></div><div class="line"> h.truncate(1024 * 4096);</div><div class="line"></div><div class="line"> <span class="comment">// Launch 8 coroutines, each writing 4Kb of chars 0-8 to every 32Kb block</span></div><div class="line"> <span class="keyword">auto</span> coroutine = [&h](<span class="keywordtype">size_t</span> no) -> std::future<void> {</div><div class="line"> std::vector<llfio::byte, llfio::utils::page_allocator<llfio::byte>> buffer(4096);</div><div class="line"> memset(buffer.data(), (int) (<span class="charliteral">'0'</span> + no), 4096);</div><div class="line"> llfio::async_file_handle::const_buffer_type bt{buffer.data(), buffer.size()};</div><div class="line"> <span class="keywordflow">for</span>(<span class="keywordtype">size_t</span> n = 0; n < 128; n++)</div><div class="line"> {</div><div class="line"> <span class="comment">// This will initiate the i/o, and suspend the coroutine until completion.</span></div><div class="line"> <span class="comment">// The caller will thus resume execution with a valid unsignaled future.</span></div><div class="line"> <span class="keyword">auto</span> written = co_await h.co_write({bt, n * 32768 + no * 4096}).value();</div><div class="line"> written.value();</div><div class="line"> }</div><div class="line"> };</div><div class="line"> std::vector<std::future<void>> coroutines;</div><div class="line"> <span class="keywordflow">for</span>(<span class="keywordtype">size_t</span> n = 0; n < 8; n++)</div><div class="line"> {</div><div class="line"> <span class="comment">// Construct each coroutine, initiating the i/o, then suspending.</span></div><div class="line"> coroutines.push_back(coroutine(n));</div><div class="line"> }</div><div class="line"> <span class="comment">// Pump the i/o, multiplexing the coroutines, until no more work remains.</span></div><div class="line"> <span class="keywordflow">while</span>(service.run().value())</div><div class="line"> ;</div><div class="line"> <span class="comment">// Make sure nothing went wrong by fetching the futures.</span></div><div class="line"> <span class="keywordflow">for</span>(<span class="keyword">auto</span> &i : coroutines)</div><div class="line"> {</div><div class="line"> i.get();</div><div class="line"> }</div></div><!-- fragment --></div><h2 class="groupheader">Constructor & Destructor Documentation</h2> diff --git a/classllfio__v2__xxx_1_1map__handle.html b/classllfio__v2__xxx_1_1map__handle.html index ec1d9d81..53ec463b 100644 --- a/classllfio__v2__xxx_1_1map__handle.html +++ b/classllfio__v2__xxx_1_1map__handle.html @@ -442,7 +442,7 @@ class </td><td class="memItemRight" valign="bottom"><b>mapped_file_handle</ <p>The native handle returned by this map handle is always that of the backing storage, but closing this handle does not close that of the backing storage, nor does releasing this handle release that of the backing storage. Locking byte ranges of this handle is therefore equal to locking byte ranges in the original backing storage, which can be very useful.</p> <h2>Barriers:</h2> <p><code>map_handle</code>, because it implements <code>io_handle</code>, implements <code>barrier()</code> in a very conservative way to account for OS differences i.e. it calls <code>msync()</code>, and then the <code>barrier()</code> implementation for the backing file (probably <code>fsync()</code> or equivalent on most platforms, which synchronises the entire file).</p> -<p>This is vast overkill if you are using non-volatile RAM, so a special <em>inlined</em> <code>barrier()</code> implementation taking a single buffer and no other arguments is also provided. This calls the appropriate architecture-specific instructions to cause the CPU to write all preceding writes out of the write buffers and CPU caches to main memory, so for Intel CPUs this would be <code>CLWB <each cache line>; SFENCE;</code>. As this is inlined, it ought to produce optimal code. If your CPU does not support the requisite instructions (or AFIO has not added support), and empty buffer will be returned to indicate that nothing was barriered, same as the normal <code>barrier()</code> function.</p> +<p>This is vast overkill if you are using non-volatile RAM, so a special <em>inlined</em> <code>barrier()</code> implementation taking a single buffer and no other arguments is also provided. This calls the appropriate architecture-specific instructions to cause the CPU to write all preceding writes out of the write buffers and CPU caches to main memory, so for Intel CPUs this would be <code>CLWB <each cache line>; SFENCE;</code>. As this is inlined, it ought to produce optimal code. If your CPU does not support the requisite instructions (or LLFIO has not added support), and empty buffer will be returned to indicate that nothing was barriered, same as the normal <code>barrier()</code> function.</p> <dl class="section see"><dt>See also</dt><dd><code>mapped_file_handle</code>, <code>algorithm::mapped_span</code> </dd></dl> </div><h2 class="groupheader">Member Enumeration Documentation</h2> <a id="a5929f46f42112bd805ab5001bfbf9d2a"></a> @@ -473,9 +473,9 @@ class </td><td class="memItemRight" valign="bottom"><b>mapped_file_handle</ </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa334c4a4c42fdb79d7ebc3e73b517e6f8"></a>none </td><td class="fielddoc"><p>No caching whatsoever, all reads and writes come from storage (i.e. <code>O_DIRECT|O_SYNC</code>). Align all i/o to 4Kb boundaries for this to work. <code>flag_disable_safety_fsyncs</code> can be used here. </p> </td></tr> -<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962"></a>unlink_on_first_close </td><td class="fielddoc"><p>Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed to by <code>path()</code> upon the call of <code>close()</code> 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 <code>errc::resource_unavailable_try_again</code> error return. Because this is confusing, unless the <code>win_disable_unlink_emulation</code> flag is also specified, this POSIX behaviour is somewhat emulated by AFIO on older Windows by renaming the file to a random name on <code>close()</code> causing it to appear to have been unlinked immediately. </p> +<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962"></a>unlink_on_first_close </td><td class="fielddoc"><p>Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed to by <code>path()</code> upon the call of <code>close()</code> 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 <code>errc::resource_unavailable_try_again</code> error return. Because this is confusing, unless the <code>win_disable_unlink_emulation</code> flag is also specified, this POSIX behaviour is somewhat emulated by LLFIO on older Windows by renaming the file to a random name on <code>close()</code> causing it to appear to have been unlinked immediately. </p> </td></tr> -<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9"></a>disable_safety_fsyncs </td><td class="fielddoc"><p>Some kernel caching modes have unhelpfully inconsistent behaviours in getting your data onto storage, so by default unless this flag is specified AFIO 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.</p> +<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9"></a>disable_safety_fsyncs </td><td class="fielddoc"><p>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.</p> <p>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.</p> <p>This only occurs for these kernel caching modes: caching::none caching::reads caching::reads_and_metadata caching::safety_fsyncs </p> </td></tr> @@ -489,7 +489,7 @@ class </td><td class="memItemRight" valign="bottom"><b>mapped_file_handle</ </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0"></a>win_disable_sparse_file_creation </td><td class="fielddoc"><p>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.</p> <p>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.</p> -<p>As extents-based storage is nearly cost free on NTFS, AFIO 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. </p> +<p>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. </p> </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a"></a>overlapped </td><td class="fielddoc"><p>On Windows, create any new handles with OVERLAPPED semantics. </p> </td></tr> @@ -498,7 +498,7 @@ class </td><td class="memItemRight" valign="bottom"><b>mapped_file_handle</ <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"></a>anonymous_inode </td><td class="fielddoc"><p>This is an inode created with no representation on the filing system. </p> </td></tr> </table> -<div class="fragment"><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>  {</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a> = 0, <span class="comment">//!< No flags</span></div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span> <span class="comment"></span><span class="comment"> /*! Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed</span></div><div class="line"><a name="l00101"></a><span class="lineno"> 101</span> <span class="comment"> to by `path()` upon the call of `close()` if and only if the inode matches. On Windows,</span></div><div class="line"><a name="l00102"></a><span class="lineno"> 102</span> <span class="comment"> if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous</span></div><div class="line"><a name="l00103"></a><span class="lineno"> 103</span> <span class="comment"> editions of Windows, the file entry does not disappears but becomes unavailable for</span></div><div class="line"><a name="l00104"></a><span class="lineno"> 104</span> <span class="comment"> anyone else to open with an `errc::resource_unavailable_try_again` error return. Because this is confusing, unless the</span></div><div class="line"><a name="l00105"></a><span class="lineno"> 105</span> <span class="comment"> `win_disable_unlink_emulation` flag is also specified, this POSIX behaviour is</span></div><div class="line"><a name="l00106"></a><span class="lineno"> 106</span> <span class="comment"> somewhat emulated by AFIO on older Windows by renaming the file to a random name on `close()`</span></div><div class="line"><a name="l00107"></a><span class="lineno"> 107</span> <span class="comment"> causing it to appear to have been unlinked immediately.</span></div><div class="line"><a name="l00108"></a><span class="lineno"> 108</span> <span class="comment"> */</span></div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">unlink_on_first_close</a> = 1U << 0U,</div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span> <span class="comment"></span></div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span> <span class="comment"> /*! Some kernel caching modes have unhelpfully inconsistent behaviours</span></div><div class="line"><a name="l00112"></a><span class="lineno"> 112</span> <span class="comment"> in getting your data onto storage, so by default unless this flag is</span></div><div class="line"><a name="l00113"></a><span class="lineno"> 113</span> <span class="comment"> specified AFIO adds extra fsyncs to the following operations for the</span></div><div class="line"><a name="l00114"></a><span class="lineno"> 114</span> <span class="comment"> caching modes specified below:</span></div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span> <span class="comment"> * truncation of file length either explicitly or during file open.</span></div><div class="line"><a name="l00116"></a><span class="lineno"> 116</span> <span class="comment"> * closing of the handle either explicitly or in the destructor.</span></div><div class="line"><a name="l00117"></a><span class="lineno"> 117</span> <span class="comment"></span></div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span> <span class="comment"> Additionally on Linux only to prevent loss of file metadata:</span></div><div class="line"><a name="l00119"></a><span class="lineno"> 119</span> <span class="comment"> * On the parent directory whenever a file might have been created.</span></div><div class="line"><a name="l00120"></a><span class="lineno"> 120</span> <span class="comment"> * On the parent directory on file close.</span></div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span> <span class="comment"></span></div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span> <span class="comment"> This only occurs for these kernel caching modes:</span></div><div class="line"><a name="l00123"></a><span class="lineno"> 123</span> <span class="comment"> * caching::none</span></div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span> <span class="comment"> * caching::reads</span></div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span> <span class="comment"> * caching::reads_and_metadata</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> <span class="comment"> * caching::safety_fsyncs</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> <span class="comment"> */</span></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9">disable_safety_fsyncs</a> = 1U << 2U,<span class="comment"></span></div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span> <span class="comment"> /*! `file_handle::unlink()` could accidentally delete the wrong file if someone has</span></div><div class="line"><a name="l00130"></a><span class="lineno"> 130</span> <span class="comment"> renamed the open file handle since the time it was opened. To prevent this occuring,</span></div><div class="line"><a name="l00131"></a><span class="lineno"> 131</span> <span class="comment"> where the OS doesn't provide race free unlink-by-open-handle we compare the inode of</span></div><div class="line"><a name="l00132"></a><span class="lineno"> 132</span> <span class="comment"> the path we are about to unlink with that of the open handle before unlinking.</span></div><div class="line"><a name="l00133"></a><span class="lineno"> 133</span> <span class="comment"> \warning This does not prevent races where in between the time of checking the inode</span></div><div class="line"><a name="l00134"></a><span class="lineno"> 134</span> <span class="comment"> and executing the unlink a third party changes the item about to be unlinked. Only</span></div><div class="line"><a name="l00135"></a><span class="lineno"> 135</span> <span class="comment"> operating systems with a true race-free unlink syscall are race free.</span></div><div class="line"><a name="l00136"></a><span class="lineno"> 136</span> <span class="comment"> */</span></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">disable_safety_unlinks</a> = 1U << 3U,<span class="comment"></span></div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span> <span class="comment"> /*! Ask the OS to disable prefetching of data. This can improve random</span></div><div class="line"><a name="l00139"></a><span class="lineno"> 139</span> <span class="comment"> i/o performance.</span></div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span> <span class="comment"> */</span></div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">disable_prefetching</a> = 1U << 4U,<span class="comment"></span></div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span> <span class="comment"> /*! Ask the OS to maximise prefetching of data, possibly prefetching the entire file</span></div><div class="line"><a name="l00143"></a><span class="lineno"> 143</span> <span class="comment"> into kernel cache. This can improve sequential i/o performance.</span></div><div class="line"><a name="l00144"></a><span class="lineno"> 144</span> <span class="comment"> */</span></div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">maximum_prefetching</a> = 1U << 5U,</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span> </div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">win_disable_unlink_emulation</a> = 1U << 24U, <span class="comment">//!< See the documentation for `unlink_on_first_close`</span></div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span> <span class="comment"></span><span class="comment"> /*! Microsoft Windows NTFS, having been created in the late 1980s, did not originally</span></div><div class="line"><a name="l00149"></a><span class="lineno"> 149</span> <span class="comment"> implement extents-based storage and thus could only represent sparse files via</span></div><div class="line"><a name="l00150"></a><span class="lineno"> 150</span> <span class="comment"> efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000),</span></div><div class="line"><a name="l00151"></a><span class="lineno"> 151</span> <span class="comment"> a proper extents-based on-storage representation was added, thus allowing only 64Kb</span></div><div class="line"><a name="l00152"></a><span class="lineno"> 152</span> <span class="comment"> extent chunks written to be stored irrespective of whatever the maximum file extent</span></div><div class="line"><a name="l00153"></a><span class="lineno"> 153</span> <span class="comment"> was set to.</span></div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span> <span class="comment"></span></div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span> <span class="comment"> For various historical reasons, extents-based storage is disabled by default in newly</span></div><div class="line"><a name="l00156"></a><span class="lineno"> 156</span> <span class="comment"> created files on NTFS, unlike in almost every other major filing system. You have to</span></div><div class="line"><a name="l00157"></a><span class="lineno"> 157</span> <span class="comment"> explicitly "opt in" to extents-based storage.</span></div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span> <span class="comment"></span></div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span> <span class="comment"> As extents-based storage is nearly cost free on NTFS, AFIO by default opts in to</span></div><div class="line"><a name="l00160"></a><span class="lineno"> 160</span> <span class="comment"> extents-based storage for any empty file it creates. If you don't want this, you</span></div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span> <span class="comment"> can specify this flag to prevent that happening.</span></div><div class="line"><a name="l00162"></a><span class="lineno"> 162</span> <span class="comment"> */</span></div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">win_disable_sparse_file_creation</a> = 1U << 25U,</div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span> </div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span>  <span class="comment">// NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!</span></div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span> </div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">overlapped</a> = 1U << 28U, <span class="comment">//!< On Windows, create any new handles with OVERLAPPED semantics</span></div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">byte_lock_insanity</a> = 1U << 29U, <span class="comment">//!< Using insane POSIX byte range locks</span></div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">anonymous_inode</a> = 1U << 30U <span class="comment">//!< This is an inode created with no representation on the filing system</span></div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span> <span class="comment"></span> }</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">llfio_v2_xxx::handle::anonymous_inode</a></div><div class="ttdoc">This is an inode created with no representation on the filing system. </div><div class="ttdef"><b>Definition:</b> handle.hpp:169</div></div> +<div class="fragment"><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>  {</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a> = 0, <span class="comment">//!< No flags</span></div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span> <span class="comment"></span><span class="comment"> /*! Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed</span></div><div class="line"><a name="l00101"></a><span class="lineno"> 101</span> <span class="comment"> to by `path()` upon the call of `close()` if and only if the inode matches. On Windows,</span></div><div class="line"><a name="l00102"></a><span class="lineno"> 102</span> <span class="comment"> if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous</span></div><div class="line"><a name="l00103"></a><span class="lineno"> 103</span> <span class="comment"> editions of Windows, the file entry does not disappears but becomes unavailable for</span></div><div class="line"><a name="l00104"></a><span class="lineno"> 104</span> <span class="comment"> anyone else to open with an `errc::resource_unavailable_try_again` error return. Because this is confusing, unless the</span></div><div class="line"><a name="l00105"></a><span class="lineno"> 105</span> <span class="comment"> `win_disable_unlink_emulation` flag is also specified, this POSIX behaviour is</span></div><div class="line"><a name="l00106"></a><span class="lineno"> 106</span> <span class="comment"> somewhat emulated by LLFIO on older Windows by renaming the file to a random name on `close()`</span></div><div class="line"><a name="l00107"></a><span class="lineno"> 107</span> <span class="comment"> causing it to appear to have been unlinked immediately.</span></div><div class="line"><a name="l00108"></a><span class="lineno"> 108</span> <span class="comment"> */</span></div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">unlink_on_first_close</a> = 1U << 0U,</div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span> <span class="comment"></span></div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span> <span class="comment"> /*! Some kernel caching modes have unhelpfully inconsistent behaviours</span></div><div class="line"><a name="l00112"></a><span class="lineno"> 112</span> <span class="comment"> in getting your data onto storage, so by default unless this flag is</span></div><div class="line"><a name="l00113"></a><span class="lineno"> 113</span> <span class="comment"> specified LLFIO adds extra fsyncs to the following operations for the</span></div><div class="line"><a name="l00114"></a><span class="lineno"> 114</span> <span class="comment"> caching modes specified below:</span></div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span> <span class="comment"> * truncation of file length either explicitly or during file open.</span></div><div class="line"><a name="l00116"></a><span class="lineno"> 116</span> <span class="comment"> * closing of the handle either explicitly or in the destructor.</span></div><div class="line"><a name="l00117"></a><span class="lineno"> 117</span> <span class="comment"></span></div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span> <span class="comment"> Additionally on Linux only to prevent loss of file metadata:</span></div><div class="line"><a name="l00119"></a><span class="lineno"> 119</span> <span class="comment"> * On the parent directory whenever a file might have been created.</span></div><div class="line"><a name="l00120"></a><span class="lineno"> 120</span> <span class="comment"> * On the parent directory on file close.</span></div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span> <span class="comment"></span></div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span> <span class="comment"> This only occurs for these kernel caching modes:</span></div><div class="line"><a name="l00123"></a><span class="lineno"> 123</span> <span class="comment"> * caching::none</span></div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span> <span class="comment"> * caching::reads</span></div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span> <span class="comment"> * caching::reads_and_metadata</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> <span class="comment"> * caching::safety_fsyncs</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> <span class="comment"> */</span></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9">disable_safety_fsyncs</a> = 1U << 2U,<span class="comment"></span></div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span> <span class="comment"> /*! `file_handle::unlink()` could accidentally delete the wrong file if someone has</span></div><div class="line"><a name="l00130"></a><span class="lineno"> 130</span> <span class="comment"> renamed the open file handle since the time it was opened. To prevent this occuring,</span></div><div class="line"><a name="l00131"></a><span class="lineno"> 131</span> <span class="comment"> where the OS doesn't provide race free unlink-by-open-handle we compare the inode of</span></div><div class="line"><a name="l00132"></a><span class="lineno"> 132</span> <span class="comment"> the path we are about to unlink with that of the open handle before unlinking.</span></div><div class="line"><a name="l00133"></a><span class="lineno"> 133</span> <span class="comment"> \warning This does not prevent races where in between the time of checking the inode</span></div><div class="line"><a name="l00134"></a><span class="lineno"> 134</span> <span class="comment"> and executing the unlink a third party changes the item about to be unlinked. Only</span></div><div class="line"><a name="l00135"></a><span class="lineno"> 135</span> <span class="comment"> operating systems with a true race-free unlink syscall are race free.</span></div><div class="line"><a name="l00136"></a><span class="lineno"> 136</span> <span class="comment"> */</span></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">disable_safety_unlinks</a> = 1U << 3U,<span class="comment"></span></div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span> <span class="comment"> /*! Ask the OS to disable prefetching of data. This can improve random</span></div><div class="line"><a name="l00139"></a><span class="lineno"> 139</span> <span class="comment"> i/o performance.</span></div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span> <span class="comment"> */</span></div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">disable_prefetching</a> = 1U << 4U,<span class="comment"></span></div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span> <span class="comment"> /*! Ask the OS to maximise prefetching of data, possibly prefetching the entire file</span></div><div class="line"><a name="l00143"></a><span class="lineno"> 143</span> <span class="comment"> into kernel cache. This can improve sequential i/o performance.</span></div><div class="line"><a name="l00144"></a><span class="lineno"> 144</span> <span class="comment"> */</span></div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">maximum_prefetching</a> = 1U << 5U,</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span> </div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">win_disable_unlink_emulation</a> = 1U << 24U, <span class="comment">//!< See the documentation for `unlink_on_first_close`</span></div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span> <span class="comment"></span><span class="comment"> /*! Microsoft Windows NTFS, having been created in the late 1980s, did not originally</span></div><div class="line"><a name="l00149"></a><span class="lineno"> 149</span> <span class="comment"> implement extents-based storage and thus could only represent sparse files via</span></div><div class="line"><a name="l00150"></a><span class="lineno"> 150</span> <span class="comment"> efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000),</span></div><div class="line"><a name="l00151"></a><span class="lineno"> 151</span> <span class="comment"> a proper extents-based on-storage representation was added, thus allowing only 64Kb</span></div><div class="line"><a name="l00152"></a><span class="lineno"> 152</span> <span class="comment"> extent chunks written to be stored irrespective of whatever the maximum file extent</span></div><div class="line"><a name="l00153"></a><span class="lineno"> 153</span> <span class="comment"> was set to.</span></div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span> <span class="comment"></span></div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span> <span class="comment"> For various historical reasons, extents-based storage is disabled by default in newly</span></div><div class="line"><a name="l00156"></a><span class="lineno"> 156</span> <span class="comment"> created files on NTFS, unlike in almost every other major filing system. You have to</span></div><div class="line"><a name="l00157"></a><span class="lineno"> 157</span> <span class="comment"> explicitly "opt in" to extents-based storage.</span></div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span> <span class="comment"></span></div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span> <span class="comment"> As extents-based storage is nearly cost free on NTFS, LLFIO by default opts in to</span></div><div class="line"><a name="l00160"></a><span class="lineno"> 160</span> <span class="comment"> extents-based storage for any empty file it creates. If you don't want this, you</span></div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span> <span class="comment"> can specify this flag to prevent that happening.</span></div><div class="line"><a name="l00162"></a><span class="lineno"> 162</span> <span class="comment"> */</span></div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">win_disable_sparse_file_creation</a> = 1U << 25U,</div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span> </div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span>  <span class="comment">// NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!</span></div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span> </div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">overlapped</a> = 1U << 28U, <span class="comment">//!< On Windows, create any new handles with OVERLAPPED semantics</span></div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">byte_lock_insanity</a> = 1U << 29U, <span class="comment">//!< Using insane POSIX byte range locks</span></div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">anonymous_inode</a> = 1U << 30U <span class="comment">//!< This is an inode created with no representation on the filing system</span></div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span> <span class="comment"></span> }</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">llfio_v2_xxx::handle::anonymous_inode</a></div><div class="ttdoc">This is an inode created with no representation on the filing system. </div><div class="ttdef"><b>Definition:</b> handle.hpp:169</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">llfio_v2_xxx::handle::disable_safety_unlinks</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:137</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">llfio_v2_xxx::handle::none</a></div><div class="ttdoc">No flags. </div><div class="ttdef"><b>Definition:</b> handle.hpp:99</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">llfio_v2_xxx::handle::maximum_prefetching</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:145</div></div> @@ -621,7 +621,7 @@ For portability, you can only assume that barriers write order for a single hand </table> </dd> </dl> -<p>Upon return, one knows that memory in the returned buffer has been barriered (it may be empty if there is no support for this operation in AFIO, or if the current CPU does not support this operation). You may find the <code>is_nvram()</code> observer of particular use here. </p> +<p>Upon return, one knows that memory in the returned buffer has been barriered (it may be empty if there is no support for this operation in LLFIO, or if the current CPU does not support this operation). You may find the <code>is_nvram()</code> observer of particular use here. </p> <div class="fragment"><div class="line"><a name="l00364"></a><span class="lineno"> 364</span>  {</div><div class="line"><a name="l00365"></a><span class="lineno"> 365</span>  const_buffer_type ret{(<a class="code" href="structllfio__v2__xxx_1_1io__handle_1_1const__buffer__type.html#a56b1347a75286b1b21af8082faacabb7">const_buffer_type::pointer</a>)(((uintptr_t) req.data) & 31), 0};</div><div class="line"><a name="l00366"></a><span class="lineno"> 366</span>  ret.<a class="code" href="structllfio__v2__xxx_1_1io__handle_1_1const__buffer__type.html#a78be763b5fa330d6c43a9ebe39f83a3e">len</a> = req.data + req.len - ret.data;</div><div class="line"><a name="l00367"></a><span class="lineno"> 367</span>  <span class="keywordflow">for</span>(<a class="code" href="structllfio__v2__xxx_1_1io__handle_1_1const__buffer__type.html#a56b1347a75286b1b21af8082faacabb7">const_buffer_type::pointer</a> addr = ret.data; addr < ret.data + ret.len; addr += 32)</div><div class="line"><a name="l00368"></a><span class="lineno"> 368</span>  {</div><div class="line"><a name="l00369"></a><span class="lineno"> 369</span>  <span class="comment">// Slightly UB ...</span></div><div class="line"><a name="l00370"></a><span class="lineno"> 370</span>  <span class="keyword">auto</span> *p = <span class="keyword">reinterpret_cast<</span><span class="keyword">const </span>persistent<byte> *<span class="keyword">></span>(addr);</div><div class="line"><a name="l00371"></a><span class="lineno"> 371</span>  <span class="keywordflow">if</span>(memory_flush_none == p->flush(evict ? memory_flush_evict : memory_flush_retain))</div><div class="line"><a name="l00372"></a><span class="lineno"> 372</span>  {</div><div class="line"><a name="l00373"></a><span class="lineno"> 373</span>  req.len = 0;</div><div class="line"><a name="l00374"></a><span class="lineno"> 374</span>  <span class="keywordflow">break</span>;</div><div class="line"><a name="l00375"></a><span class="lineno"> 375</span>  }</div><div class="line"><a name="l00376"></a><span class="lineno"> 376</span>  }</div><div class="line"><a name="l00377"></a><span class="lineno"> 377</span>  <span class="keywordflow">return</span> ret;</div><div class="line"><a name="l00378"></a><span class="lineno"> 378</span>  }</div><div class="ttc" id="structllfio__v2__xxx_1_1io__handle_1_1const__buffer__type_html_a78be763b5fa330d6c43a9ebe39f83a3e"><div class="ttname"><a href="structllfio__v2__xxx_1_1io__handle_1_1const__buffer__type.html#a78be763b5fa330d6c43a9ebe39f83a3e">llfio_v2_xxx::io_handle::const_buffer_type::len</a></div><div class="ttdeci">size_type len</div><div class="ttdoc">The number of bytes to write from this address. Try to make this a 64 byte multiple, or ideally, a whole multiple of page_size(). </div><div class="ttdef"><b>Definition:</b> io_handle.hpp:98</div></div> <div class="ttc" id="structllfio__v2__xxx_1_1io__handle_1_1const__buffer__type_html_a56b1347a75286b1b21af8082faacabb7"><div class="ttname"><a href="structllfio__v2__xxx_1_1io__handle_1_1const__buffer__type.html#a56b1347a75286b1b21af8082faacabb7">llfio_v2_xxx::io_handle::const_buffer_type::pointer</a></div><div class="ttdeci">const byte * pointer</div><div class="ttdoc">Type of the pointer to memory. </div><div class="ttdef"><b>Definition:</b> io_handle.hpp:87</div></div> </div><!-- fragment --> @@ -677,8 +677,8 @@ For portability, you can only assume that barriers write order for a single hand </table> </div><div class="memdoc"> <p>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.</p> -<p>If AFIO 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, AFIO 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 <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> -<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in AFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call AFIO appropriately.</p> +<p>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 <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> +<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in LLFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call LLFIO appropriately.</p> <dl class="section warning"><dt>Warning</dt><dd>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 <b>can change randomly at any moment</b>. Most code written to use absolute file systems paths is <b>racy</b>, so don't do it, use <code>path_handle</code> to fix a base location on the file system and work from that anchor instead!</dd></dl> <dl class="section user"><dt>Memory Allocations</dt><dd>At least one malloc for the <code>path_type</code>, likely several more. </dd></dl> <dl class="section see"><dt>See also</dt><dd><code>algorithm::cached_parent_handle_adapter<T></code> 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. </dd></dl> diff --git a/classllfio__v2__xxx_1_1mapped__file__handle.html b/classllfio__v2__xxx_1_1mapped__file__handle.html index 16be0639..6ef1f389 100644 --- a/classllfio__v2__xxx_1_1mapped__file__handle.html +++ b/classllfio__v2__xxx_1_1mapped__file__handle.html @@ -539,9 +539,9 @@ ino_t </td><td class="memItemRight" valign="bottom"><b>_inode</b> {0}</td>< </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa334c4a4c42fdb79d7ebc3e73b517e6f8"></a>none </td><td class="fielddoc"><p>No caching whatsoever, all reads and writes come from storage (i.e. <code>O_DIRECT|O_SYNC</code>). Align all i/o to 4Kb boundaries for this to work. <code>flag_disable_safety_fsyncs</code> can be used here. </p> </td></tr> -<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962"></a>unlink_on_first_close </td><td class="fielddoc"><p>Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed to by <code>path()</code> upon the call of <code>close()</code> 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 <code>errc::resource_unavailable_try_again</code> error return. Because this is confusing, unless the <code>win_disable_unlink_emulation</code> flag is also specified, this POSIX behaviour is somewhat emulated by AFIO on older Windows by renaming the file to a random name on <code>close()</code> causing it to appear to have been unlinked immediately. </p> +<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962"></a>unlink_on_first_close </td><td class="fielddoc"><p>Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed to by <code>path()</code> upon the call of <code>close()</code> 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 <code>errc::resource_unavailable_try_again</code> error return. Because this is confusing, unless the <code>win_disable_unlink_emulation</code> flag is also specified, this POSIX behaviour is somewhat emulated by LLFIO on older Windows by renaming the file to a random name on <code>close()</code> causing it to appear to have been unlinked immediately. </p> </td></tr> -<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9"></a>disable_safety_fsyncs </td><td class="fielddoc"><p>Some kernel caching modes have unhelpfully inconsistent behaviours in getting your data onto storage, so by default unless this flag is specified AFIO 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.</p> +<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9"></a>disable_safety_fsyncs </td><td class="fielddoc"><p>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.</p> <p>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.</p> <p>This only occurs for these kernel caching modes: caching::none caching::reads caching::reads_and_metadata caching::safety_fsyncs </p> </td></tr> @@ -555,7 +555,7 @@ ino_t </td><td class="memItemRight" valign="bottom"><b>_inode</b> {0}</td>< </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0"></a>win_disable_sparse_file_creation </td><td class="fielddoc"><p>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.</p> <p>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.</p> -<p>As extents-based storage is nearly cost free on NTFS, AFIO 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. </p> +<p>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. </p> </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a"></a>overlapped </td><td class="fielddoc"><p>On Windows, create any new handles with OVERLAPPED semantics. </p> </td></tr> @@ -564,7 +564,7 @@ ino_t </td><td class="memItemRight" valign="bottom"><b>_inode</b> {0}</td>< <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"></a>anonymous_inode </td><td class="fielddoc"><p>This is an inode created with no representation on the filing system. </p> </td></tr> </table> -<div class="fragment"><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>  {</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a> = 0, <span class="comment">//!< No flags</span></div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span> <span class="comment"></span><span class="comment"> /*! Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed</span></div><div class="line"><a name="l00101"></a><span class="lineno"> 101</span> <span class="comment"> to by `path()` upon the call of `close()` if and only if the inode matches. On Windows,</span></div><div class="line"><a name="l00102"></a><span class="lineno"> 102</span> <span class="comment"> if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous</span></div><div class="line"><a name="l00103"></a><span class="lineno"> 103</span> <span class="comment"> editions of Windows, the file entry does not disappears but becomes unavailable for</span></div><div class="line"><a name="l00104"></a><span class="lineno"> 104</span> <span class="comment"> anyone else to open with an `errc::resource_unavailable_try_again` error return. Because this is confusing, unless the</span></div><div class="line"><a name="l00105"></a><span class="lineno"> 105</span> <span class="comment"> `win_disable_unlink_emulation` flag is also specified, this POSIX behaviour is</span></div><div class="line"><a name="l00106"></a><span class="lineno"> 106</span> <span class="comment"> somewhat emulated by AFIO on older Windows by renaming the file to a random name on `close()`</span></div><div class="line"><a name="l00107"></a><span class="lineno"> 107</span> <span class="comment"> causing it to appear to have been unlinked immediately.</span></div><div class="line"><a name="l00108"></a><span class="lineno"> 108</span> <span class="comment"> */</span></div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">unlink_on_first_close</a> = 1U << 0U,</div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span> <span class="comment"></span></div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span> <span class="comment"> /*! Some kernel caching modes have unhelpfully inconsistent behaviours</span></div><div class="line"><a name="l00112"></a><span class="lineno"> 112</span> <span class="comment"> in getting your data onto storage, so by default unless this flag is</span></div><div class="line"><a name="l00113"></a><span class="lineno"> 113</span> <span class="comment"> specified AFIO adds extra fsyncs to the following operations for the</span></div><div class="line"><a name="l00114"></a><span class="lineno"> 114</span> <span class="comment"> caching modes specified below:</span></div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span> <span class="comment"> * truncation of file length either explicitly or during file open.</span></div><div class="line"><a name="l00116"></a><span class="lineno"> 116</span> <span class="comment"> * closing of the handle either explicitly or in the destructor.</span></div><div class="line"><a name="l00117"></a><span class="lineno"> 117</span> <span class="comment"></span></div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span> <span class="comment"> Additionally on Linux only to prevent loss of file metadata:</span></div><div class="line"><a name="l00119"></a><span class="lineno"> 119</span> <span class="comment"> * On the parent directory whenever a file might have been created.</span></div><div class="line"><a name="l00120"></a><span class="lineno"> 120</span> <span class="comment"> * On the parent directory on file close.</span></div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span> <span class="comment"></span></div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span> <span class="comment"> This only occurs for these kernel caching modes:</span></div><div class="line"><a name="l00123"></a><span class="lineno"> 123</span> <span class="comment"> * caching::none</span></div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span> <span class="comment"> * caching::reads</span></div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span> <span class="comment"> * caching::reads_and_metadata</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> <span class="comment"> * caching::safety_fsyncs</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> <span class="comment"> */</span></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9">disable_safety_fsyncs</a> = 1U << 2U,<span class="comment"></span></div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span> <span class="comment"> /*! `file_handle::unlink()` could accidentally delete the wrong file if someone has</span></div><div class="line"><a name="l00130"></a><span class="lineno"> 130</span> <span class="comment"> renamed the open file handle since the time it was opened. To prevent this occuring,</span></div><div class="line"><a name="l00131"></a><span class="lineno"> 131</span> <span class="comment"> where the OS doesn't provide race free unlink-by-open-handle we compare the inode of</span></div><div class="line"><a name="l00132"></a><span class="lineno"> 132</span> <span class="comment"> the path we are about to unlink with that of the open handle before unlinking.</span></div><div class="line"><a name="l00133"></a><span class="lineno"> 133</span> <span class="comment"> \warning This does not prevent races where in between the time of checking the inode</span></div><div class="line"><a name="l00134"></a><span class="lineno"> 134</span> <span class="comment"> and executing the unlink a third party changes the item about to be unlinked. Only</span></div><div class="line"><a name="l00135"></a><span class="lineno"> 135</span> <span class="comment"> operating systems with a true race-free unlink syscall are race free.</span></div><div class="line"><a name="l00136"></a><span class="lineno"> 136</span> <span class="comment"> */</span></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">disable_safety_unlinks</a> = 1U << 3U,<span class="comment"></span></div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span> <span class="comment"> /*! Ask the OS to disable prefetching of data. This can improve random</span></div><div class="line"><a name="l00139"></a><span class="lineno"> 139</span> <span class="comment"> i/o performance.</span></div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span> <span class="comment"> */</span></div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">disable_prefetching</a> = 1U << 4U,<span class="comment"></span></div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span> <span class="comment"> /*! Ask the OS to maximise prefetching of data, possibly prefetching the entire file</span></div><div class="line"><a name="l00143"></a><span class="lineno"> 143</span> <span class="comment"> into kernel cache. This can improve sequential i/o performance.</span></div><div class="line"><a name="l00144"></a><span class="lineno"> 144</span> <span class="comment"> */</span></div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">maximum_prefetching</a> = 1U << 5U,</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span> </div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">win_disable_unlink_emulation</a> = 1U << 24U, <span class="comment">//!< See the documentation for `unlink_on_first_close`</span></div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span> <span class="comment"></span><span class="comment"> /*! Microsoft Windows NTFS, having been created in the late 1980s, did not originally</span></div><div class="line"><a name="l00149"></a><span class="lineno"> 149</span> <span class="comment"> implement extents-based storage and thus could only represent sparse files via</span></div><div class="line"><a name="l00150"></a><span class="lineno"> 150</span> <span class="comment"> efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000),</span></div><div class="line"><a name="l00151"></a><span class="lineno"> 151</span> <span class="comment"> a proper extents-based on-storage representation was added, thus allowing only 64Kb</span></div><div class="line"><a name="l00152"></a><span class="lineno"> 152</span> <span class="comment"> extent chunks written to be stored irrespective of whatever the maximum file extent</span></div><div class="line"><a name="l00153"></a><span class="lineno"> 153</span> <span class="comment"> was set to.</span></div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span> <span class="comment"></span></div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span> <span class="comment"> For various historical reasons, extents-based storage is disabled by default in newly</span></div><div class="line"><a name="l00156"></a><span class="lineno"> 156</span> <span class="comment"> created files on NTFS, unlike in almost every other major filing system. You have to</span></div><div class="line"><a name="l00157"></a><span class="lineno"> 157</span> <span class="comment"> explicitly "opt in" to extents-based storage.</span></div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span> <span class="comment"></span></div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span> <span class="comment"> As extents-based storage is nearly cost free on NTFS, AFIO by default opts in to</span></div><div class="line"><a name="l00160"></a><span class="lineno"> 160</span> <span class="comment"> extents-based storage for any empty file it creates. If you don't want this, you</span></div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span> <span class="comment"> can specify this flag to prevent that happening.</span></div><div class="line"><a name="l00162"></a><span class="lineno"> 162</span> <span class="comment"> */</span></div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">win_disable_sparse_file_creation</a> = 1U << 25U,</div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span> </div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span>  <span class="comment">// NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!</span></div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span> </div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">overlapped</a> = 1U << 28U, <span class="comment">//!< On Windows, create any new handles with OVERLAPPED semantics</span></div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">byte_lock_insanity</a> = 1U << 29U, <span class="comment">//!< Using insane POSIX byte range locks</span></div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">anonymous_inode</a> = 1U << 30U <span class="comment">//!< This is an inode created with no representation on the filing system</span></div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span> <span class="comment"></span> }</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">llfio_v2_xxx::handle::anonymous_inode</a></div><div class="ttdoc">This is an inode created with no representation on the filing system. </div><div class="ttdef"><b>Definition:</b> handle.hpp:169</div></div> +<div class="fragment"><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>  {</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a> = 0, <span class="comment">//!< No flags</span></div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span> <span class="comment"></span><span class="comment"> /*! Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed</span></div><div class="line"><a name="l00101"></a><span class="lineno"> 101</span> <span class="comment"> to by `path()` upon the call of `close()` if and only if the inode matches. On Windows,</span></div><div class="line"><a name="l00102"></a><span class="lineno"> 102</span> <span class="comment"> if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous</span></div><div class="line"><a name="l00103"></a><span class="lineno"> 103</span> <span class="comment"> editions of Windows, the file entry does not disappears but becomes unavailable for</span></div><div class="line"><a name="l00104"></a><span class="lineno"> 104</span> <span class="comment"> anyone else to open with an `errc::resource_unavailable_try_again` error return. Because this is confusing, unless the</span></div><div class="line"><a name="l00105"></a><span class="lineno"> 105</span> <span class="comment"> `win_disable_unlink_emulation` flag is also specified, this POSIX behaviour is</span></div><div class="line"><a name="l00106"></a><span class="lineno"> 106</span> <span class="comment"> somewhat emulated by LLFIO on older Windows by renaming the file to a random name on `close()`</span></div><div class="line"><a name="l00107"></a><span class="lineno"> 107</span> <span class="comment"> causing it to appear to have been unlinked immediately.</span></div><div class="line"><a name="l00108"></a><span class="lineno"> 108</span> <span class="comment"> */</span></div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">unlink_on_first_close</a> = 1U << 0U,</div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span> <span class="comment"></span></div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span> <span class="comment"> /*! Some kernel caching modes have unhelpfully inconsistent behaviours</span></div><div class="line"><a name="l00112"></a><span class="lineno"> 112</span> <span class="comment"> in getting your data onto storage, so by default unless this flag is</span></div><div class="line"><a name="l00113"></a><span class="lineno"> 113</span> <span class="comment"> specified LLFIO adds extra fsyncs to the following operations for the</span></div><div class="line"><a name="l00114"></a><span class="lineno"> 114</span> <span class="comment"> caching modes specified below:</span></div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span> <span class="comment"> * truncation of file length either explicitly or during file open.</span></div><div class="line"><a name="l00116"></a><span class="lineno"> 116</span> <span class="comment"> * closing of the handle either explicitly or in the destructor.</span></div><div class="line"><a name="l00117"></a><span class="lineno"> 117</span> <span class="comment"></span></div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span> <span class="comment"> Additionally on Linux only to prevent loss of file metadata:</span></div><div class="line"><a name="l00119"></a><span class="lineno"> 119</span> <span class="comment"> * On the parent directory whenever a file might have been created.</span></div><div class="line"><a name="l00120"></a><span class="lineno"> 120</span> <span class="comment"> * On the parent directory on file close.</span></div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span> <span class="comment"></span></div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span> <span class="comment"> This only occurs for these kernel caching modes:</span></div><div class="line"><a name="l00123"></a><span class="lineno"> 123</span> <span class="comment"> * caching::none</span></div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span> <span class="comment"> * caching::reads</span></div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span> <span class="comment"> * caching::reads_and_metadata</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> <span class="comment"> * caching::safety_fsyncs</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> <span class="comment"> */</span></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9">disable_safety_fsyncs</a> = 1U << 2U,<span class="comment"></span></div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span> <span class="comment"> /*! `file_handle::unlink()` could accidentally delete the wrong file if someone has</span></div><div class="line"><a name="l00130"></a><span class="lineno"> 130</span> <span class="comment"> renamed the open file handle since the time it was opened. To prevent this occuring,</span></div><div class="line"><a name="l00131"></a><span class="lineno"> 131</span> <span class="comment"> where the OS doesn't provide race free unlink-by-open-handle we compare the inode of</span></div><div class="line"><a name="l00132"></a><span class="lineno"> 132</span> <span class="comment"> the path we are about to unlink with that of the open handle before unlinking.</span></div><div class="line"><a name="l00133"></a><span class="lineno"> 133</span> <span class="comment"> \warning This does not prevent races where in between the time of checking the inode</span></div><div class="line"><a name="l00134"></a><span class="lineno"> 134</span> <span class="comment"> and executing the unlink a third party changes the item about to be unlinked. Only</span></div><div class="line"><a name="l00135"></a><span class="lineno"> 135</span> <span class="comment"> operating systems with a true race-free unlink syscall are race free.</span></div><div class="line"><a name="l00136"></a><span class="lineno"> 136</span> <span class="comment"> */</span></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">disable_safety_unlinks</a> = 1U << 3U,<span class="comment"></span></div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span> <span class="comment"> /*! Ask the OS to disable prefetching of data. This can improve random</span></div><div class="line"><a name="l00139"></a><span class="lineno"> 139</span> <span class="comment"> i/o performance.</span></div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span> <span class="comment"> */</span></div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">disable_prefetching</a> = 1U << 4U,<span class="comment"></span></div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span> <span class="comment"> /*! Ask the OS to maximise prefetching of data, possibly prefetching the entire file</span></div><div class="line"><a name="l00143"></a><span class="lineno"> 143</span> <span class="comment"> into kernel cache. This can improve sequential i/o performance.</span></div><div class="line"><a name="l00144"></a><span class="lineno"> 144</span> <span class="comment"> */</span></div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">maximum_prefetching</a> = 1U << 5U,</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span> </div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">win_disable_unlink_emulation</a> = 1U << 24U, <span class="comment">//!< See the documentation for `unlink_on_first_close`</span></div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span> <span class="comment"></span><span class="comment"> /*! Microsoft Windows NTFS, having been created in the late 1980s, did not originally</span></div><div class="line"><a name="l00149"></a><span class="lineno"> 149</span> <span class="comment"> implement extents-based storage and thus could only represent sparse files via</span></div><div class="line"><a name="l00150"></a><span class="lineno"> 150</span> <span class="comment"> efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000),</span></div><div class="line"><a name="l00151"></a><span class="lineno"> 151</span> <span class="comment"> a proper extents-based on-storage representation was added, thus allowing only 64Kb</span></div><div class="line"><a name="l00152"></a><span class="lineno"> 152</span> <span class="comment"> extent chunks written to be stored irrespective of whatever the maximum file extent</span></div><div class="line"><a name="l00153"></a><span class="lineno"> 153</span> <span class="comment"> was set to.</span></div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span> <span class="comment"></span></div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span> <span class="comment"> For various historical reasons, extents-based storage is disabled by default in newly</span></div><div class="line"><a name="l00156"></a><span class="lineno"> 156</span> <span class="comment"> created files on NTFS, unlike in almost every other major filing system. You have to</span></div><div class="line"><a name="l00157"></a><span class="lineno"> 157</span> <span class="comment"> explicitly "opt in" to extents-based storage.</span></div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span> <span class="comment"></span></div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span> <span class="comment"> As extents-based storage is nearly cost free on NTFS, LLFIO by default opts in to</span></div><div class="line"><a name="l00160"></a><span class="lineno"> 160</span> <span class="comment"> extents-based storage for any empty file it creates. If you don't want this, you</span></div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span> <span class="comment"> can specify this flag to prevent that happening.</span></div><div class="line"><a name="l00162"></a><span class="lineno"> 162</span> <span class="comment"> */</span></div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">win_disable_sparse_file_creation</a> = 1U << 25U,</div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span> </div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span>  <span class="comment">// NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!</span></div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span> </div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">overlapped</a> = 1U << 28U, <span class="comment">//!< On Windows, create any new handles with OVERLAPPED semantics</span></div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">byte_lock_insanity</a> = 1U << 29U, <span class="comment">//!< Using insane POSIX byte range locks</span></div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">anonymous_inode</a> = 1U << 30U <span class="comment">//!< This is an inode created with no representation on the filing system</span></div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span> <span class="comment"></span> }</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">llfio_v2_xxx::handle::anonymous_inode</a></div><div class="ttdoc">This is an inode created with no representation on the filing system. </div><div class="ttdef"><b>Definition:</b> handle.hpp:169</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">llfio_v2_xxx::handle::disable_safety_unlinks</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:137</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">llfio_v2_xxx::handle::none</a></div><div class="ttdoc">No flags. </div><div class="ttdef"><b>Definition:</b> handle.hpp:99</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">llfio_v2_xxx::handle::maximum_prefetching</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:145</div></div> @@ -747,8 +747,8 @@ For portability, you can only assume that barriers write order for a single hand </table> </div><div class="memdoc"> <p>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.</p> -<p>If AFIO 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, AFIO 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 <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> -<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in AFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call AFIO appropriately.</p> +<p>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 <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> +<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in LLFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call LLFIO appropriately.</p> <dl class="section warning"><dt>Warning</dt><dd>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 <b>can change randomly at any moment</b>. Most code written to use absolute file systems paths is <b>racy</b>, so don't do it, use <code>path_handle</code> to fix a base location on the file system and work from that anchor instead!</dd></dl> <dl class="section user"><dt>Memory Allocations</dt><dd>At least one malloc for the <code>path_type</code>, likely several more. </dd></dl> <dl class="section see"><dt>See also</dt><dd><code>algorithm::cached_parent_handle_adapter<T></code> 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. </dd></dl> diff --git a/classllfio__v2__xxx_1_1path__handle.html b/classllfio__v2__xxx_1_1path__handle.html index 06e620d9..79706d30 100644 --- a/classllfio__v2__xxx_1_1path__handle.html +++ b/classllfio__v2__xxx_1_1path__handle.html @@ -337,9 +337,9 @@ class </td><td class="memItemRight" valign="bottom"><b>directory_handle</b> </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa334c4a4c42fdb79d7ebc3e73b517e6f8"></a>none </td><td class="fielddoc"><p>No caching whatsoever, all reads and writes come from storage (i.e. <code>O_DIRECT|O_SYNC</code>). Align all i/o to 4Kb boundaries for this to work. <code>flag_disable_safety_fsyncs</code> can be used here. </p> </td></tr> -<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962"></a>unlink_on_first_close </td><td class="fielddoc"><p>Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed to by <code>path()</code> upon the call of <code>close()</code> 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 <code>errc::resource_unavailable_try_again</code> error return. Because this is confusing, unless the <code>win_disable_unlink_emulation</code> flag is also specified, this POSIX behaviour is somewhat emulated by AFIO on older Windows by renaming the file to a random name on <code>close()</code> causing it to appear to have been unlinked immediately. </p> +<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962"></a>unlink_on_first_close </td><td class="fielddoc"><p>Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed to by <code>path()</code> upon the call of <code>close()</code> 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 <code>errc::resource_unavailable_try_again</code> error return. Because this is confusing, unless the <code>win_disable_unlink_emulation</code> flag is also specified, this POSIX behaviour is somewhat emulated by LLFIO on older Windows by renaming the file to a random name on <code>close()</code> causing it to appear to have been unlinked immediately. </p> </td></tr> -<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9"></a>disable_safety_fsyncs </td><td class="fielddoc"><p>Some kernel caching modes have unhelpfully inconsistent behaviours in getting your data onto storage, so by default unless this flag is specified AFIO 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.</p> +<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9"></a>disable_safety_fsyncs </td><td class="fielddoc"><p>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.</p> <p>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.</p> <p>This only occurs for these kernel caching modes: caching::none caching::reads caching::reads_and_metadata caching::safety_fsyncs </p> </td></tr> @@ -353,7 +353,7 @@ class </td><td class="memItemRight" valign="bottom"><b>directory_handle</b> </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0"></a>win_disable_sparse_file_creation </td><td class="fielddoc"><p>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.</p> <p>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.</p> -<p>As extents-based storage is nearly cost free on NTFS, AFIO 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. </p> +<p>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. </p> </td></tr> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a"></a>overlapped </td><td class="fielddoc"><p>On Windows, create any new handles with OVERLAPPED semantics. </p> </td></tr> @@ -362,7 +362,7 @@ class </td><td class="memItemRight" valign="bottom"><b>directory_handle</b> <tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"></a>anonymous_inode </td><td class="fielddoc"><p>This is an inode created with no representation on the filing system. </p> </td></tr> </table> -<div class="fragment"><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>  {</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a> = 0, <span class="comment">//!< No flags</span></div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span> <span class="comment"></span><span class="comment"> /*! Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed</span></div><div class="line"><a name="l00101"></a><span class="lineno"> 101</span> <span class="comment"> to by `path()` upon the call of `close()` if and only if the inode matches. On Windows,</span></div><div class="line"><a name="l00102"></a><span class="lineno"> 102</span> <span class="comment"> if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous</span></div><div class="line"><a name="l00103"></a><span class="lineno"> 103</span> <span class="comment"> editions of Windows, the file entry does not disappears but becomes unavailable for</span></div><div class="line"><a name="l00104"></a><span class="lineno"> 104</span> <span class="comment"> anyone else to open with an `errc::resource_unavailable_try_again` error return. Because this is confusing, unless the</span></div><div class="line"><a name="l00105"></a><span class="lineno"> 105</span> <span class="comment"> `win_disable_unlink_emulation` flag is also specified, this POSIX behaviour is</span></div><div class="line"><a name="l00106"></a><span class="lineno"> 106</span> <span class="comment"> somewhat emulated by AFIO on older Windows by renaming the file to a random name on `close()`</span></div><div class="line"><a name="l00107"></a><span class="lineno"> 107</span> <span class="comment"> causing it to appear to have been unlinked immediately.</span></div><div class="line"><a name="l00108"></a><span class="lineno"> 108</span> <span class="comment"> */</span></div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">unlink_on_first_close</a> = 1U << 0U,</div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span> <span class="comment"></span></div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span> <span class="comment"> /*! Some kernel caching modes have unhelpfully inconsistent behaviours</span></div><div class="line"><a name="l00112"></a><span class="lineno"> 112</span> <span class="comment"> in getting your data onto storage, so by default unless this flag is</span></div><div class="line"><a name="l00113"></a><span class="lineno"> 113</span> <span class="comment"> specified AFIO adds extra fsyncs to the following operations for the</span></div><div class="line"><a name="l00114"></a><span class="lineno"> 114</span> <span class="comment"> caching modes specified below:</span></div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span> <span class="comment"> * truncation of file length either explicitly or during file open.</span></div><div class="line"><a name="l00116"></a><span class="lineno"> 116</span> <span class="comment"> * closing of the handle either explicitly or in the destructor.</span></div><div class="line"><a name="l00117"></a><span class="lineno"> 117</span> <span class="comment"></span></div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span> <span class="comment"> Additionally on Linux only to prevent loss of file metadata:</span></div><div class="line"><a name="l00119"></a><span class="lineno"> 119</span> <span class="comment"> * On the parent directory whenever a file might have been created.</span></div><div class="line"><a name="l00120"></a><span class="lineno"> 120</span> <span class="comment"> * On the parent directory on file close.</span></div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span> <span class="comment"></span></div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span> <span class="comment"> This only occurs for these kernel caching modes:</span></div><div class="line"><a name="l00123"></a><span class="lineno"> 123</span> <span class="comment"> * caching::none</span></div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span> <span class="comment"> * caching::reads</span></div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span> <span class="comment"> * caching::reads_and_metadata</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> <span class="comment"> * caching::safety_fsyncs</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> <span class="comment"> */</span></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9">disable_safety_fsyncs</a> = 1U << 2U,<span class="comment"></span></div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span> <span class="comment"> /*! `file_handle::unlink()` could accidentally delete the wrong file if someone has</span></div><div class="line"><a name="l00130"></a><span class="lineno"> 130</span> <span class="comment"> renamed the open file handle since the time it was opened. To prevent this occuring,</span></div><div class="line"><a name="l00131"></a><span class="lineno"> 131</span> <span class="comment"> where the OS doesn't provide race free unlink-by-open-handle we compare the inode of</span></div><div class="line"><a name="l00132"></a><span class="lineno"> 132</span> <span class="comment"> the path we are about to unlink with that of the open handle before unlinking.</span></div><div class="line"><a name="l00133"></a><span class="lineno"> 133</span> <span class="comment"> \warning This does not prevent races where in between the time of checking the inode</span></div><div class="line"><a name="l00134"></a><span class="lineno"> 134</span> <span class="comment"> and executing the unlink a third party changes the item about to be unlinked. Only</span></div><div class="line"><a name="l00135"></a><span class="lineno"> 135</span> <span class="comment"> operating systems with a true race-free unlink syscall are race free.</span></div><div class="line"><a name="l00136"></a><span class="lineno"> 136</span> <span class="comment"> */</span></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">disable_safety_unlinks</a> = 1U << 3U,<span class="comment"></span></div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span> <span class="comment"> /*! Ask the OS to disable prefetching of data. This can improve random</span></div><div class="line"><a name="l00139"></a><span class="lineno"> 139</span> <span class="comment"> i/o performance.</span></div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span> <span class="comment"> */</span></div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">disable_prefetching</a> = 1U << 4U,<span class="comment"></span></div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span> <span class="comment"> /*! Ask the OS to maximise prefetching of data, possibly prefetching the entire file</span></div><div class="line"><a name="l00143"></a><span class="lineno"> 143</span> <span class="comment"> into kernel cache. This can improve sequential i/o performance.</span></div><div class="line"><a name="l00144"></a><span class="lineno"> 144</span> <span class="comment"> */</span></div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">maximum_prefetching</a> = 1U << 5U,</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span> </div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">win_disable_unlink_emulation</a> = 1U << 24U, <span class="comment">//!< See the documentation for `unlink_on_first_close`</span></div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span> <span class="comment"></span><span class="comment"> /*! Microsoft Windows NTFS, having been created in the late 1980s, did not originally</span></div><div class="line"><a name="l00149"></a><span class="lineno"> 149</span> <span class="comment"> implement extents-based storage and thus could only represent sparse files via</span></div><div class="line"><a name="l00150"></a><span class="lineno"> 150</span> <span class="comment"> efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000),</span></div><div class="line"><a name="l00151"></a><span class="lineno"> 151</span> <span class="comment"> a proper extents-based on-storage representation was added, thus allowing only 64Kb</span></div><div class="line"><a name="l00152"></a><span class="lineno"> 152</span> <span class="comment"> extent chunks written to be stored irrespective of whatever the maximum file extent</span></div><div class="line"><a name="l00153"></a><span class="lineno"> 153</span> <span class="comment"> was set to.</span></div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span> <span class="comment"></span></div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span> <span class="comment"> For various historical reasons, extents-based storage is disabled by default in newly</span></div><div class="line"><a name="l00156"></a><span class="lineno"> 156</span> <span class="comment"> created files on NTFS, unlike in almost every other major filing system. You have to</span></div><div class="line"><a name="l00157"></a><span class="lineno"> 157</span> <span class="comment"> explicitly "opt in" to extents-based storage.</span></div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span> <span class="comment"></span></div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span> <span class="comment"> As extents-based storage is nearly cost free on NTFS, AFIO by default opts in to</span></div><div class="line"><a name="l00160"></a><span class="lineno"> 160</span> <span class="comment"> extents-based storage for any empty file it creates. If you don't want this, you</span></div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span> <span class="comment"> can specify this flag to prevent that happening.</span></div><div class="line"><a name="l00162"></a><span class="lineno"> 162</span> <span class="comment"> */</span></div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">win_disable_sparse_file_creation</a> = 1U << 25U,</div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span> </div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span>  <span class="comment">// NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!</span></div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span> </div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">overlapped</a> = 1U << 28U, <span class="comment">//!< On Windows, create any new handles with OVERLAPPED semantics</span></div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">byte_lock_insanity</a> = 1U << 29U, <span class="comment">//!< Using insane POSIX byte range locks</span></div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">anonymous_inode</a> = 1U << 30U <span class="comment">//!< This is an inode created with no representation on the filing system</span></div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span> <span class="comment"></span> }</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">llfio_v2_xxx::handle::anonymous_inode</a></div><div class="ttdoc">This is an inode created with no representation on the filing system. </div><div class="ttdef"><b>Definition:</b> handle.hpp:169</div></div> +<div class="fragment"><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>  {</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a> = 0, <span class="comment">//!< No flags</span></div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span> <span class="comment"></span><span class="comment"> /*! Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed</span></div><div class="line"><a name="l00101"></a><span class="lineno"> 101</span> <span class="comment"> to by `path()` upon the call of `close()` if and only if the inode matches. On Windows,</span></div><div class="line"><a name="l00102"></a><span class="lineno"> 102</span> <span class="comment"> if you are on Windows 10 1709 or later, exactly the same thing occurs. If on previous</span></div><div class="line"><a name="l00103"></a><span class="lineno"> 103</span> <span class="comment"> editions of Windows, the file entry does not disappears but becomes unavailable for</span></div><div class="line"><a name="l00104"></a><span class="lineno"> 104</span> <span class="comment"> anyone else to open with an `errc::resource_unavailable_try_again` error return. Because this is confusing, unless the</span></div><div class="line"><a name="l00105"></a><span class="lineno"> 105</span> <span class="comment"> `win_disable_unlink_emulation` flag is also specified, this POSIX behaviour is</span></div><div class="line"><a name="l00106"></a><span class="lineno"> 106</span> <span class="comment"> somewhat emulated by LLFIO on older Windows by renaming the file to a random name on `close()`</span></div><div class="line"><a name="l00107"></a><span class="lineno"> 107</span> <span class="comment"> causing it to appear to have been unlinked immediately.</span></div><div class="line"><a name="l00108"></a><span class="lineno"> 108</span> <span class="comment"> */</span></div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">unlink_on_first_close</a> = 1U << 0U,</div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span> <span class="comment"></span></div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span> <span class="comment"> /*! Some kernel caching modes have unhelpfully inconsistent behaviours</span></div><div class="line"><a name="l00112"></a><span class="lineno"> 112</span> <span class="comment"> in getting your data onto storage, so by default unless this flag is</span></div><div class="line"><a name="l00113"></a><span class="lineno"> 113</span> <span class="comment"> specified LLFIO adds extra fsyncs to the following operations for the</span></div><div class="line"><a name="l00114"></a><span class="lineno"> 114</span> <span class="comment"> caching modes specified below:</span></div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span> <span class="comment"> * truncation of file length either explicitly or during file open.</span></div><div class="line"><a name="l00116"></a><span class="lineno"> 116</span> <span class="comment"> * closing of the handle either explicitly or in the destructor.</span></div><div class="line"><a name="l00117"></a><span class="lineno"> 117</span> <span class="comment"></span></div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span> <span class="comment"> Additionally on Linux only to prevent loss of file metadata:</span></div><div class="line"><a name="l00119"></a><span class="lineno"> 119</span> <span class="comment"> * On the parent directory whenever a file might have been created.</span></div><div class="line"><a name="l00120"></a><span class="lineno"> 120</span> <span class="comment"> * On the parent directory on file close.</span></div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span> <span class="comment"></span></div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span> <span class="comment"> This only occurs for these kernel caching modes:</span></div><div class="line"><a name="l00123"></a><span class="lineno"> 123</span> <span class="comment"> * caching::none</span></div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span> <span class="comment"> * caching::reads</span></div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span> <span class="comment"> * caching::reads_and_metadata</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span> <span class="comment"> * caching::safety_fsyncs</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span> <span class="comment"> */</span></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaadb5cad9e6637b574e46bc43a82a44b9">disable_safety_fsyncs</a> = 1U << 2U,<span class="comment"></span></div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span> <span class="comment"> /*! `file_handle::unlink()` could accidentally delete the wrong file if someone has</span></div><div class="line"><a name="l00130"></a><span class="lineno"> 130</span> <span class="comment"> renamed the open file handle since the time it was opened. To prevent this occuring,</span></div><div class="line"><a name="l00131"></a><span class="lineno"> 131</span> <span class="comment"> where the OS doesn't provide race free unlink-by-open-handle we compare the inode of</span></div><div class="line"><a name="l00132"></a><span class="lineno"> 132</span> <span class="comment"> the path we are about to unlink with that of the open handle before unlinking.</span></div><div class="line"><a name="l00133"></a><span class="lineno"> 133</span> <span class="comment"> \warning This does not prevent races where in between the time of checking the inode</span></div><div class="line"><a name="l00134"></a><span class="lineno"> 134</span> <span class="comment"> and executing the unlink a third party changes the item about to be unlinked. Only</span></div><div class="line"><a name="l00135"></a><span class="lineno"> 135</span> <span class="comment"> operating systems with a true race-free unlink syscall are race free.</span></div><div class="line"><a name="l00136"></a><span class="lineno"> 136</span> <span class="comment"> */</span></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">disable_safety_unlinks</a> = 1U << 3U,<span class="comment"></span></div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span> <span class="comment"> /*! Ask the OS to disable prefetching of data. This can improve random</span></div><div class="line"><a name="l00139"></a><span class="lineno"> 139</span> <span class="comment"> i/o performance.</span></div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span> <span class="comment"> */</span></div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">disable_prefetching</a> = 1U << 4U,<span class="comment"></span></div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span> <span class="comment"> /*! Ask the OS to maximise prefetching of data, possibly prefetching the entire file</span></div><div class="line"><a name="l00143"></a><span class="lineno"> 143</span> <span class="comment"> into kernel cache. This can improve sequential i/o performance.</span></div><div class="line"><a name="l00144"></a><span class="lineno"> 144</span> <span class="comment"> */</span></div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">maximum_prefetching</a> = 1U << 5U,</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span> </div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">win_disable_unlink_emulation</a> = 1U << 24U, <span class="comment">//!< See the documentation for `unlink_on_first_close`</span></div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span> <span class="comment"></span><span class="comment"> /*! Microsoft Windows NTFS, having been created in the late 1980s, did not originally</span></div><div class="line"><a name="l00149"></a><span class="lineno"> 149</span> <span class="comment"> implement extents-based storage and thus could only represent sparse files via</span></div><div class="line"><a name="l00150"></a><span class="lineno"> 150</span> <span class="comment"> efficient compression of intermediate zeros. With NTFS v3.0 (Microsoft Windows 2000),</span></div><div class="line"><a name="l00151"></a><span class="lineno"> 151</span> <span class="comment"> a proper extents-based on-storage representation was added, thus allowing only 64Kb</span></div><div class="line"><a name="l00152"></a><span class="lineno"> 152</span> <span class="comment"> extent chunks written to be stored irrespective of whatever the maximum file extent</span></div><div class="line"><a name="l00153"></a><span class="lineno"> 153</span> <span class="comment"> was set to.</span></div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span> <span class="comment"></span></div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span> <span class="comment"> For various historical reasons, extents-based storage is disabled by default in newly</span></div><div class="line"><a name="l00156"></a><span class="lineno"> 156</span> <span class="comment"> created files on NTFS, unlike in almost every other major filing system. You have to</span></div><div class="line"><a name="l00157"></a><span class="lineno"> 157</span> <span class="comment"> explicitly "opt in" to extents-based storage.</span></div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span> <span class="comment"></span></div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span> <span class="comment"> As extents-based storage is nearly cost free on NTFS, LLFIO by default opts in to</span></div><div class="line"><a name="l00160"></a><span class="lineno"> 160</span> <span class="comment"> extents-based storage for any empty file it creates. If you don't want this, you</span></div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span> <span class="comment"> can specify this flag to prevent that happening.</span></div><div class="line"><a name="l00162"></a><span class="lineno"> 162</span> <span class="comment"> */</span></div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">win_disable_sparse_file_creation</a> = 1U << 25U,</div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span> </div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span>  <span class="comment">// NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!</span></div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span> </div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span>  <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">overlapped</a> = 1U << 28U, <span class="comment">//!< On Windows, create any new handles with OVERLAPPED semantics</span></div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">byte_lock_insanity</a> = 1U << 29U, <span class="comment">//!< Using insane POSIX byte range locks</span></div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span> <span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">anonymous_inode</a> = 1U << 30U <span class="comment">//!< This is an inode created with no representation on the filing system</span></div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span> <span class="comment"></span> }</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">llfio_v2_xxx::handle::anonymous_inode</a></div><div class="ttdoc">This is an inode created with no representation on the filing system. </div><div class="ttdef"><b>Definition:</b> handle.hpp:169</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">llfio_v2_xxx::handle::disable_safety_unlinks</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:137</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">llfio_v2_xxx::handle::none</a></div><div class="ttdoc">No flags. </div><div class="ttdef"><b>Definition:</b> handle.hpp:99</div></div> <div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">llfio_v2_xxx::handle::maximum_prefetching</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:145</div></div> @@ -427,8 +427,8 @@ class </td><td class="memItemRight" valign="bottom"><b>directory_handle</b> </table> </div><div class="memdoc"> <p>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.</p> -<p>If AFIO 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, AFIO 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 <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> -<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in AFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call AFIO appropriately.</p> +<p>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 <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> +<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in LLFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call LLFIO appropriately.</p> <dl class="section warning"><dt>Warning</dt><dd>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 <b>can change randomly at any moment</b>. Most code written to use absolute file systems paths is <b>racy</b>, so don't do it, use <code>path_handle</code> to fix a base location on the file system and work from that anchor instead!</dd></dl> <dl class="section user"><dt>Memory Allocations</dt><dd>At least one malloc for the <code>path_type</code>, likely several more. </dd></dl> <dl class="section see"><dt>See also</dt><dd><code>algorithm::cached_parent_handle_adapter<T></code> 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. </dd></dl> diff --git a/classllfio__v2__xxx_1_1path__view.html b/classllfio__v2__xxx_1_1path__view.html index 2c85e2f5..c6523b00 100644 --- a/classllfio__v2__xxx_1_1path__view.html +++ b/classllfio__v2__xxx_1_1path__view.html @@ -266,11 +266,11 @@ struct </td><td class="memItemRight" valign="bottom"><b>c_str</b></td></tr> </table> <a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2> <div class="textblock"><p>A borrowed view of a path. A lightweight trivial-type alternative to <code>std::filesystem::path</code>. </p> -<p>AFIO is sufficiently fast that <code>std::filesystem::path</code> as a wrapper of an underlying <code>std::basic_string<></code> can be problematically expensive for some filing system operations due to the potential memory allocation. AFIO therefore works exclusively with borrowed views of other path storage.</p> +<p>LLFIO is sufficiently fast that <code>std::filesystem::path</code> as a wrapper of an underlying <code>std::basic_string<></code> can be problematically expensive for some filing system operations due to the potential memory allocation. LLFIO therefore works exclusively with borrowed views of other path storage.</p> <p>Some of the API for <code>std::filesystem::path</code> is replicated here, however any APIs which modify the path other than taking subsets are obviously not possible with borrowed views.</p> <dl class="todo"><dt><b><a class="el" href="todo.html#_todo000003">Todo:</a></b></dt><dd>Lots of member functions remain to be implemented.</dd></dl> <h1>Windows specific notes:</h1> -<p>Be aware that on Microsoft Windows, the native path storage <code>std::filesystem::path::value_type</code> is a <code>wchar_t</code> referring to UTF-16. However much of AFIO path usage is a <code>path_handle</code> to somewhere on the filing system plus a relative <code>const char *</code> UTF-8 path fragment as the use of absolute paths is discouraged. Rather than complicate the ABI to handle templated path character types, on Microsoft Windows only we do the following:</p> +<p>Be aware that on Microsoft Windows, the native path storage <code>std::filesystem::path::value_type</code> is a <code>wchar_t</code> referring to UTF-16. However much of LLFIO path usage is a <code>path_handle</code> to somewhere on the filing system plus a relative <code>const char *</code> UTF-8 path fragment as the use of absolute paths is discouraged. Rather than complicate the ABI to handle templated path character types, on Microsoft Windows only we do the following:</p> <ul> <li>If view input is <code>wchar_t</code>, the original source is passed through unmodified to the syscall without any memory allocation, copying nor slash conversion.</li> <li>If view input is <code>char</code>:<ol type="1"> @@ -280,10 +280,10 @@ struct </td><td class="memItemRight" valign="bottom"><b>c_str</b></td></tr> </ol> </li> </ul> -<p>AFIO calls the NT kernel API directly rather than the Win32 API for:</p> +<p>LLFIO calls the NT kernel API directly rather than the Win32 API for:</p> <ul> <li>For any paths relative to a <code>path_handle</code> (the Win32 API does not provide a race free file system API).</li> -<li>For any paths beginning with <code>\!!\</code>, we pass the path + 3 characters directly through. This prefix is a pure AFIO extension, and will not be recognised by other code.</li> +<li>For any paths beginning with <code>\!!\</code>, we pass the path + 3 characters directly through. This prefix is a pure LLFIO extension, and will not be recognised by other code.</li> <li>For any paths beginning with <code>\??\</code>, we pass the path + 0 characters directly through. Note the NT kernel keeps a symlink at <code>\??\</code> which refers to the DosDevices namespace for the current login, so as an incorrect relation which you should <b>not</b> rely on, the Win32 path <code>C:\foo</code> probably will appear at <code>\??\C:\foo</code>.</li> </ul> <p>These prefixes are still passed to the Win32 API:</p> diff --git a/classllfio__v2__xxx_1_1section__handle.html b/classllfio__v2__xxx_1_1section__handle.html index 0da5be71..136289e4 100644 --- a/classllfio__v2__xxx_1_1section__handle.html +++ b/classllfio__v2__xxx_1_1section__handle.html @@ -573,8 +573,8 @@ flag </td><td class="memItemRight" valign="bottom"><b>_flags</b> {flag::non </table> </div><div class="memdoc"> <p>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.</p> -<p>If AFIO 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, AFIO 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 <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> -<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in AFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call AFIO appropriately.</p> +<p>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 <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> +<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in LLFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call LLFIO appropriately.</p> <dl class="section warning"><dt>Warning</dt><dd>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 <b>can change randomly at any moment</b>. Most code written to use absolute file systems paths is <b>racy</b>, so don't do it, use <code>path_handle</code> to fix a base location on the file system and work from that anchor instead!</dd></dl> <dl class="section user"><dt>Memory Allocations</dt><dd>At least one malloc for the <code>path_type</code>, likely several more. </dd></dl> <dl class="section see"><dt>See also</dt><dd><code>algorithm::cached_parent_handle_adapter<T></code> 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. </dd></dl> diff --git a/config_8hpp.html b/config_8hpp.html index 03b26e87..b750b781 100644 --- a/config_8hpp.html +++ b/config_8hpp.html @@ -91,7 +91,7 @@ $(document).ready(function(){initNavTree('config_8hpp.html','');}); </div><!--header--> <div class="contents"> -<p>Configures a compiler environment for AFIO header and source code. +<p>Configures a compiler environment for LLFIO header and source code. <a href="#details">More...</a></p> <div class="textblock"><code>#include <iostream></code><br /> <code>#include "quickcpplib/include/cpp_feature.h"</code><br /> @@ -116,7 +116,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:namespacellfio__v2__xxx_1_1algorithm"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx_1_1algorithm.html">llfio_v2_xxx::algorithm</a></td></tr> <tr class="memdesc:namespacellfio__v2__xxx_1_1algorithm"><td class="mdescLeft"> </td><td class="mdescRight">Collection of file system based algorithms. <br /></td></tr> @@ -125,14 +125,14 @@ Namespaces</h2></td></tr> <tr class="memdesc:namespacellfio__v2__xxx_1_1storage__profile"><td class="mdescLeft"> </td><td class="mdescRight">YAML databaseable empirical testing of a storage's behaviour. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:namespacellfio__v2__xxx_1_1utils"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx_1_1utils.html">llfio_v2_xxx::utils</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx_1_1utils"><td class="mdescLeft"> </td><td class="mdescRight">Utility routines often useful when using AFIO. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx_1_1utils"><td class="mdescLeft"> </td><td class="mdescRight">Utility routines often useful when using LLFIO. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table><table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="define-members"></a> Macros</h2></td></tr> <tr class="memitem:ga5365e6c96107a8e7edf6030462562cae"><td class="memItemLeft" align="right" valign="top"> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#ga5365e6c96107a8e7edf6030462562cae">LLFIO_HEADERS_ONLY</a>   1</td></tr> -<tr class="memdesc:ga5365e6c96107a8e7edf6030462562cae"><td class="mdescLeft"> </td><td class="mdescRight">Whether AFIO is a headers only library. Defaults to 1 unless BOOST_ALL_DYN_LINK is defined. <br /></td></tr> +<tr class="memdesc:ga5365e6c96107a8e7edf6030462562cae"><td class="mdescLeft"> </td><td class="mdescRight">Whether LLFIO is a headers only library. Defaults to 1 unless BOOST_ALL_DYN_LINK is defined. <br /></td></tr> <tr class="separator:ga5365e6c96107a8e7edf6030462562cae"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:a65d3346e1345f27d02cfe4ef4d7c9c3a"><td class="memItemLeft" align="right" valign="top"><a id="a65d3346e1345f27d02cfe4ef4d7c9c3a"></a> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="config_8hpp.html#a65d3346e1345f27d02cfe4ef4d7c9c3a">LLFIO_DISABLE_PATHS_IN_FAILURE_INFO</a>   not defined</td></tr> @@ -160,21 +160,21 @@ Macros</h2></td></tr> <tr class="separator:aebebb7d8d2589a39eba3e0e84cb26559"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:gabb964a24682a722a7eaad891ee497a61"><td class="memItemLeft" align="right" valign="top"> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#gabb964a24682a722a7eaad891ee497a61">LLFIO_V2</a>   (QUICKCPPLIB_BIND_NAMESPACE_VERSION(llfio_v2))</td></tr> -<tr class="memdesc:gabb964a24682a722a7eaad891ee497a61"><td class="mdescLeft"> </td><td class="mdescRight">The namespace configuration of this AFIO v2. Consists of a sequence of bracketed tokens later fused by the preprocessor into namespace and C++ module names. <br /></td></tr> +<tr class="memdesc:gabb964a24682a722a7eaad891ee497a61"><td class="mdescLeft"> </td><td class="mdescRight">The namespace configuration of this LLFIO v2. Consists of a sequence of bracketed tokens later fused by the preprocessor into namespace and C++ module names. <br /></td></tr> <tr class="separator:gabb964a24682a722a7eaad891ee497a61"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:gac9f7f0153adb9034d26c4554728f817a"><td class="memItemLeft" align="right" valign="top"> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#gac9f7f0153adb9034d26c4554728f817a">LLFIO_V2_NAMESPACE</a>   llfio_v2_xxx</td></tr> -<tr class="memdesc:gac9f7f0153adb9034d26c4554728f817a"><td class="mdescLeft"> </td><td class="mdescRight">The namespace of this AFIO v2 which will be some unknown inline namespace starting with <code>v2_</code> inside the <code>boost::llfio</code> namespace. <br /></td></tr> +<tr class="memdesc:gac9f7f0153adb9034d26c4554728f817a"><td class="mdescLeft"> </td><td class="mdescRight">The namespace of this LLFIO v2 which will be some unknown inline namespace starting with <code>v2_</code> inside the <code>boost::llfio</code> namespace. <br /></td></tr> <tr class="separator:gac9f7f0153adb9034d26c4554728f817a"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:gae1eb04a1ef4089291c04f60a66b9849e"><td class="memItemLeft" align="right" valign="top">#define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#gae1eb04a1ef4089291c04f60a66b9849e">LLFIO_V2_NAMESPACE_BEGIN</a></td></tr> -<tr class="memdesc:gae1eb04a1ef4089291c04f60a66b9849e"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate namespace markup to enter the AFIO v2 namespace. <a href="group__config.html#gae1eb04a1ef4089291c04f60a66b9849e">More...</a><br /></td></tr> +<tr class="memdesc:gae1eb04a1ef4089291c04f60a66b9849e"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate namespace markup to enter the LLFIO v2 namespace. <a href="group__config.html#gae1eb04a1ef4089291c04f60a66b9849e">More...</a><br /></td></tr> <tr class="separator:gae1eb04a1ef4089291c04f60a66b9849e"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:gab2f82803f0ce479a2993d3b7696db8d3"><td class="memItemLeft" align="right" valign="top">#define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#gab2f82803f0ce479a2993d3b7696db8d3">LLFIO_V2_NAMESPACE_EXPORT_BEGIN</a></td></tr> -<tr class="memdesc:gab2f82803f0ce479a2993d3b7696db8d3"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate namespace markup to enter the C++ module exported AFIO v2 namespace. <a href="group__config.html#gab2f82803f0ce479a2993d3b7696db8d3">More...</a><br /></td></tr> +<tr class="memdesc:gab2f82803f0ce479a2993d3b7696db8d3"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate namespace markup to enter the C++ module exported LLFIO v2 namespace. <a href="group__config.html#gab2f82803f0ce479a2993d3b7696db8d3">More...</a><br /></td></tr> <tr class="separator:gab2f82803f0ce479a2993d3b7696db8d3"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:ga84df5d479525cd6b58f873c2f9869b22"><td class="memItemLeft" align="right" valign="top"> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#ga84df5d479525cd6b58f873c2f9869b22">LLFIO_V2_NAMESPACE_END</a>   }</td></tr> -<tr class="memdesc:ga84df5d479525cd6b58f873c2f9869b22"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate namespace markup to exit the AFIO v2 namespace. <br /></td></tr> +<tr class="memdesc:ga84df5d479525cd6b58f873c2f9869b22"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate namespace markup to exit the LLFIO v2 namespace. <br /></td></tr> <tr class="separator:ga84df5d479525cd6b58f873c2f9869b22"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:a163aaaaa4d238aebd5fb9acec82006dd"><td class="memItemLeft" align="right" valign="top"><a id="a163aaaaa4d238aebd5fb9acec82006dd"></a> #define </td><td class="memItemRight" valign="bottom"><b>LLFIO_DECL</b></td></tr> @@ -211,15 +211,15 @@ Macros</h2></td></tr> <tr class="separator:aa96417d97962da23b27d237508a58646"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:ga48fcb899a9d482d406f8fdbebc791ba0"><td class="memItemLeft" align="right" valign="top"> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#ga48fcb899a9d482d406f8fdbebc791ba0">LLFIO_HEADERS_ONLY_FUNC_SPEC</a>   inline</td></tr> -<tr class="memdesc:ga48fcb899a9d482d406f8fdbebc791ba0"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate markup to declare an <code>extern</code> function exported from the AFIO DLL if not building headers only. <br /></td></tr> +<tr class="memdesc:ga48fcb899a9d482d406f8fdbebc791ba0"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate markup to declare an <code>extern</code> function exported from the LLFIO DLL if not building headers only. <br /></td></tr> <tr class="separator:ga48fcb899a9d482d406f8fdbebc791ba0"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:gad270840dbd547a75ad62d48e93412ca7"><td class="memItemLeft" align="right" valign="top"> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#gad270840dbd547a75ad62d48e93412ca7">LLFIO_HEADERS_ONLY_MEMFUNC_SPEC</a>   inline</td></tr> -<tr class="memdesc:gad270840dbd547a75ad62d48e93412ca7"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate markup to declare a class member function exported from the AFIO DLL if not building headers only. <br /></td></tr> +<tr class="memdesc:gad270840dbd547a75ad62d48e93412ca7"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate markup to declare a class member function exported from the LLFIO DLL if not building headers only. <br /></td></tr> <tr class="separator:gad270840dbd547a75ad62d48e93412ca7"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:ga40c15a3fc44361077b478acbfaca18ee"><td class="memItemLeft" align="right" valign="top"> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#ga40c15a3fc44361077b478acbfaca18ee">LLFIO_HEADERS_ONLY_VIRTUAL_SPEC</a>   inline virtual</td></tr> -<tr class="memdesc:ga40c15a3fc44361077b478acbfaca18ee"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate markup to declare a virtual class member function exported from the AFIO DLL if not building headers only. <br /></td></tr> +<tr class="memdesc:ga40c15a3fc44361077b478acbfaca18ee"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate markup to declare a virtual class member function exported from the LLFIO DLL if not building headers only. <br /></td></tr> <tr class="separator:ga40c15a3fc44361077b478acbfaca18ee"><td class="memSeparator" colspan="2"> </td></tr> </table><table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="typedef-members"></a> @@ -249,7 +249,7 @@ template<class R , class U , class... Args> </td></tr> <tr class="separator:ace72a598b9cabfc3d6f6760895e893fd"><td class="memSeparator" colspan="2"> </td></tr> </table> <a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2> -<div class="textblock"><p>Configures a compiler environment for AFIO header and source code. </p> +<div class="textblock"><p>Configures a compiler environment for LLFIO header and source code. </p> </div></div><!-- contents --> </div><!-- doc-content --> <!-- start footer part --> diff --git a/deadline_8h.html b/deadline_8h.html index 3f6c5eb6..4cf29e92 100644 --- a/deadline_8h.html +++ b/deadline_8h.html @@ -105,7 +105,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table><table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="define-members"></a> diff --git a/dir_9ffbcff25eb6a2bb8ed044f6c5d983c9.html b/dir_9ffbcff25eb6a2bb8ed044f6c5d983c9.html index 9b298b39..2e989c91 100644 --- a/dir_9ffbcff25eb6a2bb8ed044f6c5d983c9.html +++ b/dir_9ffbcff25eb6a2bb8ed044f6c5d983c9.html @@ -91,10 +91,10 @@ Directories</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="files"></a> Files</h2></td></tr> <tr class="memitem:llfio_8hpp"><td class="memItemLeft" align="right" valign="top">file  </td><td class="memItemRight" valign="bottom"><a class="el" href="llfio_8hpp.html">llfio.hpp</a></td></tr> -<tr class="memdesc:llfio_8hpp"><td class="mdescLeft"> </td><td class="mdescRight">The master <em>latest version</em> AFIO include file. All AFIO consuming libraries should include this header only. <br /></td></tr> +<tr class="memdesc:llfio_8hpp"><td class="mdescLeft"> </td><td class="mdescRight">The master <em>latest version</em> LLFIO include file. All LLFIO consuming libraries should include this header only. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:version_8hpp"><td class="memItemLeft" align="right" valign="top">file  </td><td class="memItemRight" valign="bottom"><a class="el" href="version_8hpp.html">version.hpp</a></td></tr> -<tr class="memdesc:version_8hpp"><td class="mdescLeft"> </td><td class="mdescRight">Controls the version of AFIO for cmake, shared library and C++ namespace mangling. <br /></td></tr> +<tr class="memdesc:version_8hpp"><td class="mdescLeft"> </td><td class="mdescRight">Controls the version of LLFIO for cmake, shared library and C++ namespace mangling. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table> </div><!-- contents --> diff --git a/dir_ff8d8ad368a820031e12dd9b12d79036.html b/dir_ff8d8ad368a820031e12dd9b12d79036.html index 06e6d798..ed5522ea 100644 --- a/dir_ff8d8ad368a820031e12dd9b12d79036.html +++ b/dir_ff8d8ad368a820031e12dd9b12d79036.html @@ -94,7 +94,7 @@ Files</h2></td></tr> <tr class="memdesc:async__file__handle_8hpp"><td class="mdescLeft"> </td><td class="mdescRight">Provides async_file_handle. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:config_8hpp"><td class="memItemLeft" align="right" valign="top">file  </td><td class="memItemRight" valign="bottom"><a class="el" href="config_8hpp.html">config.hpp</a></td></tr> -<tr class="memdesc:config_8hpp"><td class="mdescLeft"> </td><td class="mdescRight">Configures a compiler environment for AFIO header and source code. <br /></td></tr> +<tr class="memdesc:config_8hpp"><td class="mdescLeft"> </td><td class="mdescRight">Configures a compiler environment for LLFIO header and source code. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:deadline_8h"><td class="memItemLeft" align="right" valign="top">file  </td><td class="memItemRight" valign="bottom"><a class="el" href="deadline_8h.html">deadline.h</a></td></tr> <tr class="memdesc:deadline_8h"><td class="mdescLeft"> </td><td class="mdescRight">Provides struct deadline. <br /></td></tr> @@ -118,7 +118,7 @@ Files</h2></td></tr> <tr class="memdesc:io__service_8hpp"><td class="mdescLeft"> </td><td class="mdescRight">Provides io_service. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:v2_80_2llfio_8hpp"><td class="memItemLeft" align="right" valign="top">file  </td><td class="memItemRight" valign="bottom"><a class="el" href="v2_80_2llfio_8hpp.html">llfio.hpp</a></td></tr> -<tr class="memdesc:v2_80_2llfio_8hpp"><td class="mdescLeft"> </td><td class="mdescRight">The master <em>versioned</em> AFIO include file. All version specific AFIO consuming libraries should include this header only. <br /></td></tr> +<tr class="memdesc:v2_80_2llfio_8hpp"><td class="mdescLeft"> </td><td class="mdescRight">The master <em>versioned</em> LLFIO include file. All version specific LLFIO consuming libraries should include this header only. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:map__handle_8hpp"><td class="memItemLeft" align="right" valign="top">file  </td><td class="memItemRight" valign="bottom"><a class="el" href="map__handle_8hpp.html">map_handle.hpp</a></td></tr> <tr class="memdesc:map__handle_8hpp"><td class="mdescLeft"> </td><td class="mdescRight">Provides <code>map_handle</code> <br /></td></tr> diff --git a/directory__handle_8hpp.html b/directory__handle_8hpp.html index 6da6b69f..7b30b781 100644 --- a/directory__handle_8hpp.html +++ b/directory__handle_8hpp.html @@ -114,7 +114,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table><table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="func-members"></a> diff --git a/file__handle_8hpp.html b/file__handle_8hpp.html index 45a2d625..81d04825 100644 --- a/file__handle_8hpp.html +++ b/file__handle_8hpp.html @@ -107,7 +107,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table><table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="func-members"></a> @@ -101,7 +101,7 @@ $(document).ready(function(){initNavTree('files.html','');}); <tr id="row_0_0_0_0_2_" class="even"><td class="entry"><span style="width:80px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="mapped__span_8hpp.html" target="_self">mapped_span.hpp</a></td><td class="desc">Provides typed view of mapped section </td></tr> <tr id="row_0_0_0_0_3_"><td class="entry"><span style="width:80px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="trivial__vector_8hpp.html" target="_self">trivial_vector.hpp</a></td><td class="desc">Provides constant time reallocating STL vector </td></tr> <tr id="row_0_0_0_1_" class="even"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="async__file__handle_8hpp.html" target="_self">async_file_handle.hpp</a></td><td class="desc">Provides async_file_handle </td></tr> -<tr id="row_0_0_0_2_"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="config_8hpp.html" target="_self">config.hpp</a></td><td class="desc">Configures a compiler environment for AFIO header and source code </td></tr> +<tr id="row_0_0_0_2_"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="config_8hpp.html" target="_self">config.hpp</a></td><td class="desc">Configures a compiler environment for LLFIO header and source code </td></tr> <tr id="row_0_0_0_3_" class="even"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="deadline_8h.html" target="_self">deadline.h</a></td><td class="desc">Provides struct deadline </td></tr> <tr id="row_0_0_0_4_"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="directory__handle_8hpp.html" target="_self">directory_handle.hpp</a></td><td class="desc">Provides a handle to a directory </td></tr> <tr id="row_0_0_0_5_" class="even"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="file__handle_8hpp.html" target="_self">file_handle.hpp</a></td><td class="desc">Provides file_handle </td></tr> @@ -109,7 +109,7 @@ $(document).ready(function(){initNavTree('files.html','');}); <tr id="row_0_0_0_7_" class="even"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="handle_8hpp.html" target="_self">handle.hpp</a></td><td class="desc">Provides handle </td></tr> <tr id="row_0_0_0_8_"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="io__handle_8hpp.html" target="_self">io_handle.hpp</a></td><td class="desc">Provides i/o handle </td></tr> <tr id="row_0_0_0_9_" class="even"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="io__service_8hpp.html" target="_self">io_service.hpp</a></td><td class="desc">Provides io_service </td></tr> -<tr id="row_0_0_0_10_"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="v2_80_2llfio_8hpp.html" target="_self">llfio.hpp</a></td><td class="desc">The master <em>versioned</em> AFIO include file. All version specific AFIO consuming libraries should include this header only </td></tr> +<tr id="row_0_0_0_10_"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="v2_80_2llfio_8hpp.html" target="_self">llfio.hpp</a></td><td class="desc">The master <em>versioned</em> LLFIO include file. All version specific LLFIO consuming libraries should include this header only </td></tr> <tr id="row_0_0_0_11_" class="even"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="map__handle_8hpp.html" target="_self">map_handle.hpp</a></td><td class="desc">Provides <code>map_handle</code> </td></tr> <tr id="row_0_0_0_12_"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="mapped__file__handle_8hpp.html" target="_self">mapped_file_handle.hpp</a></td><td class="desc">Provides mapped_file_handle </td></tr> <tr id="row_0_0_0_13_" class="even"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="native__handle__type_8hpp.html" target="_self">native_handle_type.hpp</a></td><td class="desc">Provides native_handle_type </td></tr> @@ -120,8 +120,8 @@ $(document).ready(function(){initNavTree('files.html','');}); <tr id="row_0_0_0_18_"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="statfs_8hpp.html" target="_self">statfs.hpp</a></td><td class="desc">Provides statfs </td></tr> <tr id="row_0_0_0_19_" class="even"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="storage__profile_8hpp.html" target="_self">storage_profile.hpp</a></td><td class="desc">Provides storage_profile </td></tr> <tr id="row_0_0_0_20_"><td class="entry"><span style="width:64px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="utils_8hpp.html" target="_self">utils.hpp</a></td><td class="desc">Provides namespace utils </td></tr> -<tr id="row_0_0_1_" class="even"><td class="entry"><span style="width:48px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="llfio_8hpp.html" target="_self">llfio.hpp</a></td><td class="desc">The master <em>latest version</em> AFIO include file. All AFIO consuming libraries should include this header only </td></tr> -<tr id="row_0_0_2_"><td class="entry"><span style="width:48px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="version_8hpp.html" target="_self">version.hpp</a></td><td class="desc">Controls the version of AFIO for cmake, shared library and C++ namespace mangling </td></tr> +<tr id="row_0_0_1_" class="even"><td class="entry"><span style="width:48px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="llfio_8hpp.html" target="_self">llfio.hpp</a></td><td class="desc">The master <em>latest version</em> LLFIO include file. All LLFIO consuming libraries should include this header only </td></tr> +<tr id="row_0_0_2_"><td class="entry"><span style="width:48px;display:inline-block;"> </span><span class="icondoc"></span><a class="el" href="version_8hpp.html" target="_self">version.hpp</a></td><td class="desc">Controls the version of LLFIO for cmake, shared library and C++ namespace mangling </td></tr> </table> </div><!-- directory --> </div><!-- contents --> diff --git a/fs__handle_8hpp.html b/fs__handle_8hpp.html index 5d8ae734..d0e43a74 100644 --- a/fs__handle_8hpp.html +++ b/fs__handle_8hpp.html @@ -104,7 +104,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table><table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="func-members"></a> diff --git a/group__config.html b/group__config.html index 441d5b6e..37b065c3 100644 --- a/group__config.html +++ b/group__config.html @@ -107,11 +107,11 @@ Macros</h2></td></tr> <tr class="separator:ga18295c2601f9e6cb9e759d57fa0d8ab4"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:gaadd4f1f9d1a5c77c3b40d9e1b759b706"><td class="memItemLeft" align="right" valign="top"><a id="gaadd4f1f9d1a5c77c3b40d9e1b759b706"></a> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#gaadd4f1f9d1a5c77c3b40d9e1b759b706">LLFIO_UNSTABLE_VERSION</a></td></tr> -<tr class="memdesc:gaadd4f1f9d1a5c77c3b40d9e1b759b706"><td class="mdescLeft"> </td><td class="mdescRight">Defined between stable releases of AFIO. It means the inline namespace will be permuted per-commit to ensure ABI uniqueness. <br /></td></tr> +<tr class="memdesc:gaadd4f1f9d1a5c77c3b40d9e1b759b706"><td class="mdescLeft"> </td><td class="mdescRight">Defined between stable releases of LLFIO. It means the inline namespace will be permuted per-commit to ensure ABI uniqueness. <br /></td></tr> <tr class="separator:gaadd4f1f9d1a5c77c3b40d9e1b759b706"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:ga5365e6c96107a8e7edf6030462562cae"><td class="memItemLeft" align="right" valign="top"><a id="ga5365e6c96107a8e7edf6030462562cae"></a> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#ga5365e6c96107a8e7edf6030462562cae">LLFIO_HEADERS_ONLY</a>   1</td></tr> -<tr class="memdesc:ga5365e6c96107a8e7edf6030462562cae"><td class="mdescLeft"> </td><td class="mdescRight">Whether AFIO is a headers only library. Defaults to 1 unless BOOST_ALL_DYN_LINK is defined. <br /></td></tr> +<tr class="memdesc:ga5365e6c96107a8e7edf6030462562cae"><td class="mdescLeft"> </td><td class="mdescRight">Whether LLFIO is a headers only library. Defaults to 1 unless BOOST_ALL_DYN_LINK is defined. <br /></td></tr> <tr class="separator:ga5365e6c96107a8e7edf6030462562cae"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:gaf958c6b17b345d3b84043bf7352451f2"><td class="memItemLeft" align="right" valign="top"><a id="gaf958c6b17b345d3b84043bf7352451f2"></a> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#gaf958c6b17b345d3b84043bf7352451f2">LLFIO_LOGGING_LEVEL</a>   3</td></tr> @@ -127,33 +127,33 @@ Macros</h2></td></tr> <tr class="separator:ga2e45ede29ed7b2aa06eb19aff2485541"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:gabb964a24682a722a7eaad891ee497a61"><td class="memItemLeft" align="right" valign="top"><a id="gabb964a24682a722a7eaad891ee497a61"></a> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#gabb964a24682a722a7eaad891ee497a61">LLFIO_V2</a>   (QUICKCPPLIB_BIND_NAMESPACE_VERSION(llfio_v2))</td></tr> -<tr class="memdesc:gabb964a24682a722a7eaad891ee497a61"><td class="mdescLeft"> </td><td class="mdescRight">The namespace configuration of this AFIO v2. Consists of a sequence of bracketed tokens later fused by the preprocessor into namespace and C++ module names. <br /></td></tr> +<tr class="memdesc:gabb964a24682a722a7eaad891ee497a61"><td class="mdescLeft"> </td><td class="mdescRight">The namespace configuration of this LLFIO v2. Consists of a sequence of bracketed tokens later fused by the preprocessor into namespace and C++ module names. <br /></td></tr> <tr class="separator:gabb964a24682a722a7eaad891ee497a61"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:gac9f7f0153adb9034d26c4554728f817a"><td class="memItemLeft" align="right" valign="top"><a id="gac9f7f0153adb9034d26c4554728f817a"></a> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#gac9f7f0153adb9034d26c4554728f817a">LLFIO_V2_NAMESPACE</a>   llfio_v2_xxx</td></tr> -<tr class="memdesc:gac9f7f0153adb9034d26c4554728f817a"><td class="mdescLeft"> </td><td class="mdescRight">The namespace of this AFIO v2 which will be some unknown inline namespace starting with <code>v2_</code> inside the <code>boost::llfio</code> namespace. <br /></td></tr> +<tr class="memdesc:gac9f7f0153adb9034d26c4554728f817a"><td class="mdescLeft"> </td><td class="mdescRight">The namespace of this LLFIO v2 which will be some unknown inline namespace starting with <code>v2_</code> inside the <code>boost::llfio</code> namespace. <br /></td></tr> <tr class="separator:gac9f7f0153adb9034d26c4554728f817a"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:gae1eb04a1ef4089291c04f60a66b9849e"><td class="memItemLeft" align="right" valign="top">#define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#gae1eb04a1ef4089291c04f60a66b9849e">LLFIO_V2_NAMESPACE_BEGIN</a></td></tr> -<tr class="memdesc:gae1eb04a1ef4089291c04f60a66b9849e"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate namespace markup to enter the AFIO v2 namespace. <a href="#gae1eb04a1ef4089291c04f60a66b9849e">More...</a><br /></td></tr> +<tr class="memdesc:gae1eb04a1ef4089291c04f60a66b9849e"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate namespace markup to enter the LLFIO v2 namespace. <a href="#gae1eb04a1ef4089291c04f60a66b9849e">More...</a><br /></td></tr> <tr class="separator:gae1eb04a1ef4089291c04f60a66b9849e"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:gab2f82803f0ce479a2993d3b7696db8d3"><td class="memItemLeft" align="right" valign="top">#define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#gab2f82803f0ce479a2993d3b7696db8d3">LLFIO_V2_NAMESPACE_EXPORT_BEGIN</a></td></tr> -<tr class="memdesc:gab2f82803f0ce479a2993d3b7696db8d3"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate namespace markup to enter the C++ module exported AFIO v2 namespace. <a href="#gab2f82803f0ce479a2993d3b7696db8d3">More...</a><br /></td></tr> +<tr class="memdesc:gab2f82803f0ce479a2993d3b7696db8d3"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate namespace markup to enter the C++ module exported LLFIO v2 namespace. <a href="#gab2f82803f0ce479a2993d3b7696db8d3">More...</a><br /></td></tr> <tr class="separator:gab2f82803f0ce479a2993d3b7696db8d3"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:ga84df5d479525cd6b58f873c2f9869b22"><td class="memItemLeft" align="right" valign="top"><a id="ga84df5d479525cd6b58f873c2f9869b22"></a> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#ga84df5d479525cd6b58f873c2f9869b22">LLFIO_V2_NAMESPACE_END</a>   }</td></tr> -<tr class="memdesc:ga84df5d479525cd6b58f873c2f9869b22"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate namespace markup to exit the AFIO v2 namespace. <br /></td></tr> +<tr class="memdesc:ga84df5d479525cd6b58f873c2f9869b22"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate namespace markup to exit the LLFIO v2 namespace. <br /></td></tr> <tr class="separator:ga84df5d479525cd6b58f873c2f9869b22"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:ga48fcb899a9d482d406f8fdbebc791ba0"><td class="memItemLeft" align="right" valign="top"><a id="ga48fcb899a9d482d406f8fdbebc791ba0"></a> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#ga48fcb899a9d482d406f8fdbebc791ba0">LLFIO_HEADERS_ONLY_FUNC_SPEC</a>   inline</td></tr> -<tr class="memdesc:ga48fcb899a9d482d406f8fdbebc791ba0"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate markup to declare an <code>extern</code> function exported from the AFIO DLL if not building headers only. <br /></td></tr> +<tr class="memdesc:ga48fcb899a9d482d406f8fdbebc791ba0"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate markup to declare an <code>extern</code> function exported from the LLFIO DLL if not building headers only. <br /></td></tr> <tr class="separator:ga48fcb899a9d482d406f8fdbebc791ba0"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:gad270840dbd547a75ad62d48e93412ca7"><td class="memItemLeft" align="right" valign="top"><a id="gad270840dbd547a75ad62d48e93412ca7"></a> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#gad270840dbd547a75ad62d48e93412ca7">LLFIO_HEADERS_ONLY_MEMFUNC_SPEC</a>   inline</td></tr> -<tr class="memdesc:gad270840dbd547a75ad62d48e93412ca7"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate markup to declare a class member function exported from the AFIO DLL if not building headers only. <br /></td></tr> +<tr class="memdesc:gad270840dbd547a75ad62d48e93412ca7"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate markup to declare a class member function exported from the LLFIO DLL if not building headers only. <br /></td></tr> <tr class="separator:gad270840dbd547a75ad62d48e93412ca7"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:ga40c15a3fc44361077b478acbfaca18ee"><td class="memItemLeft" align="right" valign="top"><a id="ga40c15a3fc44361077b478acbfaca18ee"></a> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#ga40c15a3fc44361077b478acbfaca18ee">LLFIO_HEADERS_ONLY_VIRTUAL_SPEC</a>   inline virtual</td></tr> -<tr class="memdesc:ga40c15a3fc44361077b478acbfaca18ee"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate markup to declare a virtual class member function exported from the AFIO DLL if not building headers only. <br /></td></tr> +<tr class="memdesc:ga40c15a3fc44361077b478acbfaca18ee"><td class="mdescLeft"> </td><td class="mdescRight">Expands into the appropriate markup to declare a virtual class member function exported from the LLFIO DLL if not building headers only. <br /></td></tr> <tr class="separator:ga40c15a3fc44361077b478acbfaca18ee"><td class="memSeparator" colspan="2"> </td></tr> </table> <a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2> @@ -169,9 +169,9 @@ Macros</h2></td></tr> </tr> </table> </div><div class="memdoc"> -<b>Value:</b><div class="fragment"><div class="line"><span class="keyword">namespace </span><a class="code" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a> \</div><div class="line"> {</div><div class="ttc" id="namespacellfio__v2__xxx_html"><div class="ttname"><a href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></div><div class="ttdoc">The AFIO namespace. </div><div class="ttdef"><b>Definition:</b> config.hpp:162</div></div> +<b>Value:</b><div class="fragment"><div class="line"><span class="keyword">namespace </span><a class="code" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a> \</div><div class="line"> {</div><div class="ttc" id="namespacellfio__v2__xxx_html"><div class="ttname"><a href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></div><div class="ttdoc">The LLFIO namespace. </div><div class="ttdef"><b>Definition:</b> config.hpp:162</div></div> </div><!-- fragment --> -<p>Expands into the appropriate namespace markup to enter the AFIO v2 namespace. </p> +<p>Expands into the appropriate namespace markup to enter the LLFIO v2 namespace. </p> </div> </div> @@ -186,9 +186,9 @@ Macros</h2></td></tr> </tr> </table> </div><div class="memdoc"> -<b>Value:</b><div class="fragment"><div class="line">export <span class="keyword">namespace </span><a class="code" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a> \</div><div class="line"> {</div><div class="ttc" id="namespacellfio__v2__xxx_html"><div class="ttname"><a href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></div><div class="ttdoc">The AFIO namespace. </div><div class="ttdef"><b>Definition:</b> config.hpp:162</div></div> +<b>Value:</b><div class="fragment"><div class="line">export <span class="keyword">namespace </span><a class="code" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a> \</div><div class="line"> {</div><div class="ttc" id="namespacellfio__v2__xxx_html"><div class="ttname"><a href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></div><div class="ttdoc">The LLFIO namespace. </div><div class="ttdef"><b>Definition:</b> config.hpp:162</div></div> </div><!-- fragment --> -<p>Expands into the appropriate namespace markup to enter the C++ module exported AFIO v2 namespace. </p> +<p>Expands into the appropriate namespace markup to enter the C++ module exported LLFIO v2 namespace. </p> </div> </div> diff --git a/handle_8hpp.html b/handle_8hpp.html index a6fbd5db..2ac7d077 100644 --- a/handle_8hpp.html +++ b/handle_8hpp.html @@ -109,7 +109,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table><table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="func-members"></a> diff --git a/hierarchy.html b/hierarchy.html index 3039e3a7..ea20dc1c 100644 --- a/hierarchy.html +++ b/hierarchy.html @@ -110,7 +110,7 @@ $(document).ready(function(){initNavTree('hierarchy.html','');}); <tr id="row_21_"><td class="entry"><span style="width:16px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="classllfio__v2__xxx_1_1algorithm_1_1shared__fs__mutex_1_1shared__fs__mutex_1_1entities__guard.html" target="_self">llfio_v2_xxx::algorithm::shared_fs_mutex::shared_fs_mutex::entities_guard</a></td><td class="desc">RAII holder for a lock on a sequence of entities </td></tr> <tr id="row_22_" class="even"><td class="entry"><span style="width:16px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="structllfio__v2__xxx_1_1algorithm_1_1shared__fs__mutex_1_1shared__fs__mutex_1_1entity__type.html" target="_self">llfio_v2_xxx::algorithm::shared_fs_mutex::shared_fs_mutex::entity_type</a></td><td class="desc">The type of an entity id </td></tr> <tr id="row_23_"><td class="entry"><span style="width:16px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="structllfio__v2__xxx_1_1directory__handle_1_1enumerate__info.html" target="_self">llfio_v2_xxx::directory_handle::enumerate_info</a></td><td class="desc">Completion information for <code>enumerate()</code> </td></tr> -<tr id="row_24_" class="even"><td class="entry"><span style="width:16px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="structllfio__v2__xxx_1_1error__info.html" target="_self">llfio_v2_xxx::error_info</a></td><td class="desc">The cause of the failure of an operation in AFIO </td></tr> +<tr id="row_24_" class="even"><td class="entry"><span style="width:16px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="structllfio__v2__xxx_1_1error__info.html" target="_self">llfio_v2_xxx::error_info</a></td><td class="desc">The cause of the failure of an operation in LLFIO </td></tr> <tr id="row_25_"><td class="entry"><span style="width:16px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="classllfio__v2__xxx_1_1io__handle_1_1extent__guard.html" target="_self">llfio_v2_xxx::io_handle::extent_guard</a></td><td class="desc">RAII holder a locked extent of bytes in a file </td></tr> <tr id="row_26_" class="even"><td class="entry"><span style="width:16px;display:inline-block;"> </span><span class="icona"><span class="icon">C</span></span><a class="el" href="structllfio__v2__xxx_1_1statfs__t_1_1f__flags__t.html" target="_self">llfio_v2_xxx::statfs_t::f_flags_t</a></td><td class="desc"></td></tr> <tr id="row_27_"><td class="entry"><span style="width:0px;display:inline-block;"> </span><span id="arr_27_" class="arrow" onclick="toggleFolder('27_')">▼</span><span class="icona"><span class="icon">C</span></span><b>file_handle</b></td><td class="desc"></td></tr> @@ -92,7 +92,7 @@ $(document).ready(function(){initNavTree('index.html','');}); <img src="https://travis-ci.org/ned14/llfio.svg?branch=master"/> </div> </td><td align="center"><a href="https://ci.appveyor.com/project/ned14/llfio/branch/master">Windows CI:</a><div class="image"> -<img src="https://ci.appveyor.com/api/projects/status/680b1pt9srnoprs3/branch/master?svg=true"/> +<img src="https://ci.appveyor.com/api/projects/status/dfctqfap3kpx89om/branch/master?svg=true"/> </div> </td><td align="center"><a href="https://dedi5.nedprod.com/static/files/llfio-v2.0-source-latest.tar.xz">Latest stable</a><br /> <a href="https://dedi5.nedprod.com/static/files/llfio-v2.0-source-latest.tar.xz">sources</a> </td><td align="center"><a href="https://dedi5.nedprod.com/static/files/llfio-v2.0-binaries-linux64-latest.tgz">Latest stable</a><br /> diff --git a/io__handle_8hpp.html b/io__handle_8hpp.html index ba7a8368..5b11755c 100644 --- a/io__handle_8hpp.html +++ b/io__handle_8hpp.html @@ -117,7 +117,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table><table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="func-members"></a> diff --git a/io__service_8hpp.html b/io__service_8hpp.html index 4c5233ac..5b9fc8d0 100644 --- a/io__service_8hpp.html +++ b/io__service_8hpp.html @@ -108,7 +108,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table><table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="define-members"></a> diff --git a/llfio_8hpp.html b/llfio_8hpp.html index cc7f8555..5827adce 100644 --- a/llfio_8hpp.html +++ b/llfio_8hpp.html @@ -87,7 +87,7 @@ $(document).ready(function(){initNavTree('llfio_8hpp.html','');}); </div><!--header--> <div class="contents"> -<p>The master <em>latest version</em> AFIO include file. All AFIO consuming libraries should include this header only. +<p>The master <em>latest version</em> LLFIO include file. All LLFIO consuming libraries should include this header only. <a href="#details">More...</a></p> <div class="textblock"><code>#include "<a class="el" href="version_8hpp.html">version.hpp</a>"</code><br /> <code>#include "v2.0@E/llfio.hpp"</code><br /> @@ -105,11 +105,11 @@ Macros</h2></td></tr> <tr class="separator:ad2355e889e3d2e599f26847898c3981b"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:aa86b9d7f8bd243de24fa7077a1f31a65"><td class="memItemLeft" align="right" valign="top"><a id="aa86b9d7f8bd243de24fa7077a1f31a65"></a> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="llfio_8hpp.html#aa86b9d7f8bd243de24fa7077a1f31a65">LLFIO_HEADERS_PATH</a>   LLFIO_HEADERS_PATH3(LLFIO_HEADERS_PATH2)</td></tr> -<tr class="memdesc:aa86b9d7f8bd243de24fa7077a1f31a65"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO headers path generated by the preprocessor from the version. <br /></td></tr> +<tr class="memdesc:aa86b9d7f8bd243de24fa7077a1f31a65"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO headers path generated by the preprocessor from the version. <br /></td></tr> <tr class="separator:aa86b9d7f8bd243de24fa7077a1f31a65"><td class="memSeparator" colspan="2"> </td></tr> </table> <a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2> -<div class="textblock"><p>The master <em>latest version</em> AFIO include file. All AFIO consuming libraries should include this header only. </p> +<div class="textblock"><p>The master <em>latest version</em> LLFIO include file. All LLFIO consuming libraries should include this header only. </p> </div></div><!-- contents --> </div><!-- doc-content --> <!-- start footer part --> diff --git a/lock__files_8hpp.html b/lock__files_8hpp.html index 93854258..6fddb0db 100644 --- a/lock__files_8hpp.html +++ b/lock__files_8hpp.html @@ -103,7 +103,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:namespacellfio__v2__xxx_1_1algorithm"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx_1_1algorithm.html">llfio_v2_xxx::algorithm</a></td></tr> <tr class="memdesc:namespacellfio__v2__xxx_1_1algorithm"><td class="mdescLeft"> </td><td class="mdescRight">Collection of file system based algorithms. <br /></td></tr> diff --git a/map__handle_8hpp.html b/map__handle_8hpp.html index a632c666..66011020 100644 --- a/map__handle_8hpp.html +++ b/map__handle_8hpp.html @@ -111,7 +111,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table><table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="func-members"></a> diff --git a/mapped__file__handle_8hpp.html b/mapped__file__handle_8hpp.html index 750a0025..8ac21d95 100644 --- a/mapped__file__handle_8hpp.html +++ b/mapped__file__handle_8hpp.html @@ -105,7 +105,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table><table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="func-members"></a> diff --git a/mapped__span_8hpp.html b/mapped__span_8hpp.html index 391b2284..fa265de9 100644 --- a/mapped__span_8hpp.html +++ b/mapped__span_8hpp.html @@ -102,7 +102,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:namespacellfio__v2__xxx_1_1algorithm"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx_1_1algorithm.html">llfio_v2_xxx::algorithm</a></td></tr> <tr class="memdesc:namespacellfio__v2__xxx_1_1algorithm"><td class="mdescLeft"> </td><td class="mdescRight">Collection of file system based algorithms. <br /></td></tr> diff --git a/memory__map_8hpp.html b/memory__map_8hpp.html index 3b98392e..eb973ea7 100644 --- a/memory__map_8hpp.html +++ b/memory__map_8hpp.html @@ -107,7 +107,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:namespacellfio__v2__xxx_1_1algorithm"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx_1_1algorithm.html">llfio_v2_xxx::algorithm</a></td></tr> <tr class="memdesc:namespacellfio__v2__xxx_1_1algorithm"><td class="mdescLeft"> </td><td class="mdescRight">Collection of file system based algorithms. <br /></td></tr> diff --git a/namespacellfio__v2__xxx.html b/namespacellfio__v2__xxx.html index 41fa751f..4f35be75 100644 --- a/namespacellfio__v2__xxx.html +++ b/namespacellfio__v2__xxx.html @@ -90,7 +90,7 @@ $(document).ready(function(){initNavTree('namespacellfio__v2__xxx.html','');}); </div><!--header--> <div class="contents"> -<p>The AFIO namespace. +<p>The LLFIO namespace. <a href="#details">More...</a></p> <table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> @@ -105,7 +105,7 @@ Namespaces</h2></td></tr> <tr class="memdesc:namespacellfio__v2__xxx_1_1storage__profile"><td class="mdescLeft"> </td><td class="mdescRight">YAML databaseable empirical testing of a storage's behaviour. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:namespacellfio__v2__xxx_1_1utils"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx_1_1utils.html">utils</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx_1_1utils"><td class="mdescLeft"> </td><td class="mdescRight">Utility routines often useful when using AFIO. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx_1_1utils"><td class="mdescLeft"> </td><td class="mdescRight">Utility routines often useful when using LLFIO. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table><table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="nested-classes"></a> @@ -146,7 +146,7 @@ Classes</h2></td></tr> <tr class="memdesc:"><td class="mdescLeft"> </td><td class="mdescRight">The exception type synthesised and thrown when an <code>llfio::result</code> or <code>llfio::outcome</code> is no-value observed. <a href="classllfio__v2__xxx_1_1error.html#details">More...</a><br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:"><td class="memItemLeft" align="right" valign="top">struct  </td><td class="memItemRight" valign="bottom"><a class="el" href="structllfio__v2__xxx_1_1error__info.html">error_info</a></td></tr> -<tr class="memdesc:"><td class="mdescLeft"> </td><td class="mdescRight">The cause of the failure of an operation in AFIO. <a href="structllfio__v2__xxx_1_1error__info.html#details">More...</a><br /></td></tr> +<tr class="memdesc:"><td class="mdescLeft"> </td><td class="mdescRight">The cause of the failure of an operation in LLFIO. <a href="structllfio__v2__xxx_1_1error__info.html#details">More...</a><br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:"><td class="memItemLeft" align="right" valign="top">class  </td><td class="memItemRight" valign="bottom"><a class="el" href="classllfio__v2__xxx_1_1file__handle.html">file_handle</a></td></tr> <tr class="memdesc:"><td class="mdescLeft"> </td><td class="mdescRight">A handle to a regular file or device, kept data layout compatible with async_file_handle. <a href="classllfio__v2__xxx_1_1file__handle.html#details">More...</a><br /></td></tr> @@ -293,7 +293,7 @@ result< void > </td><td class="memItemRight" valign="bottom"><a class <tr class="separator:a4fad22759dab40321cabd37c755880fe"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:a797b0860963b9de1781023de7f9da826"><td class="memItemLeft" align="right" valign="top"><a id="a797b0860963b9de1781023de7f9da826"></a> QUICKCPPLIB_NAMESPACE::ringbuffer_log::simple_ringbuffer_log< <a class="el" href="group__config.html#ga2e45ede29ed7b2aa06eb19aff2485541">LLFIO_LOGGING_MEMORY</a> > & </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html#a797b0860963b9de1781023de7f9da826">log</a> () noexcept</td></tr> -<tr class="memdesc:a797b0860963b9de1781023de7f9da826"><td class="mdescLeft"> </td><td class="mdescRight">The log used by AFIO. <br /></td></tr> +<tr class="memdesc:a797b0860963b9de1781023de7f9da826"><td class="mdescLeft"> </td><td class="mdescRight">The log used by LLFIO. <br /></td></tr> <tr class="separator:a797b0860963b9de1781023de7f9da826"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:aaf60dc6739dc2bd7d890630b1a50d15a"><td class="memItemLeft" align="right" valign="top"><a id="aaf60dc6739dc2bd7d890630b1a50d15a"></a> std::ostream & </td><td class="memItemRight" valign="bottom"><b>operator<<</b> (std::ostream &s, const section_handle::flag &v)</td></tr> @@ -416,7 +416,7 @@ void </td><td class="memItemRight" valign="bottom"><b>outcome_throw_as_syst <tr class="separator:a20ab6481a21bf2c4cf8185919edf0a66"><td class="memSeparator" colspan="2"> </td></tr> </table> <a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2> -<div class="textblock"><p>The AFIO namespace. </p> +<div class="textblock"><p>The LLFIO namespace. </p> <dl class="todo"><dt><b><a class="el" href="todo.html#_todo000002">Todo:</a></b></dt><dd>TODO FIXME Replace in-memory log with memory map file backed log. </dd></dl> </div><h2 class="groupheader">Function Documentation</h2> <a id="a4fad22759dab40321cabd37c755880fe"></a> @@ -541,7 +541,7 @@ For portability, you can only assume that barriers write order for a single hand </table> </dd> </dl> -<p>Upon return, one knows that memory in the returned buffer has been barriered (it may be empty if there is no support for this operation in AFIO, or if the current CPU does not support this operation). You may find the <code>is_nvram()</code> observer of particular use here. </p> +<p>Upon return, one knows that memory in the returned buffer has been barriered (it may be empty if there is no support for this operation in LLFIO, or if the current CPU does not support this operation). You may find the <code>is_nvram()</code> observer of particular use here. </p> <div class="fragment"><div class="line"><a name="l00635"></a><span class="lineno"> 635</span> {</div><div class="line"><a name="l00636"></a><span class="lineno"> 636</span>  <span class="keywordflow">return</span> <span class="keyword">self</span>.barrier(std::forward<decltype(req)>(req), std::forward<decltype(evict)>(evict));</div><div class="line"><a name="l00637"></a><span class="lineno"> 637</span> }</div></div><!-- fragment --> </div> </div> @@ -604,7 +604,7 @@ For portability, you can only assume that barriers write order for a single hand </div><div class="memdoc"> <p>Create a handle opening access to a directory on path.</p> <dl class="section user"><dt>Errors returnable</dt><dd>Any of the values POSIX open() or CreateFile() can return. </dd></dl> -<div class="fragment"><div class="line"><a name="l00326"></a><span class="lineno"> 326</span> {</div><div class="line"><a name="l00327"></a><span class="lineno"> 327</span>  <span class="keywordflow">return</span> <a class="code" href="namespacellfio__v2__xxx.html#a3d112d170c1d485e1120de06eef02375">directory_handle::directory</a>(std::forward<decltype(base)>(base), std::forward<decltype(<a class="code" href="namespacellfio__v2__xxx.html#a49f7bb77eb38fbe1280019225b66b78b">path</a>)>(<a class="code" href="namespacellfio__v2__xxx.html#a49f7bb77eb38fbe1280019225b66b78b">path</a>), std::forward<decltype(_mode)>(_mode), std::forward<decltype(_creation)>(_creation), std::forward<decltype(_caching)>(_caching), std::forward<decltype(flags)>(flags));</div><div class="line"><a name="l00328"></a><span class="lineno"> 328</span> }</div><div class="ttc" id="namespacellfio__v2__xxx_html_a3d112d170c1d485e1120de06eef02375"><div class="ttname"><a href="namespacellfio__v2__xxx.html#a3d112d170c1d485e1120de06eef02375">llfio_v2_xxx::directory</a></div><div class="ttdeci">result< directory_handle > directory(const path_handle &base, directory_handle::path_view_type path, directory_handle::mode _mode=directory_handle::mode::read, directory_handle::creation _creation=directory_handle::creation::open_existing, directory_handle::caching _caching=directory_handle::caching::all, directory_handle::flag flags=directory_handle::flag::none) noexcept</div><div class="ttdef"><b>Definition:</b> directory_handle.hpp:325</div></div> +<div class="fragment"><div class="line"><a name="l00327"></a><span class="lineno"> 327</span> {</div><div class="line"><a name="l00328"></a><span class="lineno"> 328</span>  <span class="keywordflow">return</span> <a class="code" href="namespacellfio__v2__xxx.html#a3d112d170c1d485e1120de06eef02375">directory_handle::directory</a>(std::forward<decltype(base)>(base), std::forward<decltype(<a class="code" href="namespacellfio__v2__xxx.html#a49f7bb77eb38fbe1280019225b66b78b">path</a>)>(<a class="code" href="namespacellfio__v2__xxx.html#a49f7bb77eb38fbe1280019225b66b78b">path</a>), std::forward<decltype(_mode)>(_mode), std::forward<decltype(_creation)>(_creation), std::forward<decltype(_caching)>(_caching), std::forward<decltype(flags)>(flags));</div><div class="line"><a name="l00329"></a><span class="lineno"> 329</span> }</div><div class="ttc" id="namespacellfio__v2__xxx_html_a3d112d170c1d485e1120de06eef02375"><div class="ttname"><a href="namespacellfio__v2__xxx.html#a3d112d170c1d485e1120de06eef02375">llfio_v2_xxx::directory</a></div><div class="ttdeci">result< directory_handle > directory(const path_handle &base, directory_handle::path_view_type path, directory_handle::mode _mode=directory_handle::mode::read, directory_handle::creation _creation=directory_handle::creation::open_existing, directory_handle::caching _caching=directory_handle::caching::all, directory_handle::flag flags=directory_handle::flag::none) noexcept</div><div class="ttdef"><b>Definition:</b> directory_handle.hpp:325</div></div> <div class="ttc" id="namespacellfio__v2__xxx_html_a49f7bb77eb38fbe1280019225b66b78b"><div class="ttname"><a href="namespacellfio__v2__xxx.html#a49f7bb77eb38fbe1280019225b66b78b">llfio_v2_xxx::path</a></div><div class="ttdeci">result< path_handle > path(const path_handle &base, path_handle::path_view_type path) noexcept</div><div class="ttdef"><b>Definition:</b> path_handle.hpp:114</div></div> </div><!-- fragment --> </div> @@ -674,7 +674,7 @@ For portability, you can only assume that barriers write order for a single hand </dl> <dl class="section user"><dt>Errors returnable</dt><dd>todo </dd></dl> <dl class="section user"><dt>Memory Allocations</dt><dd>If the <code>kernelbuffer</code> parameter is set on entry, no memory allocations. If unset, at least one memory allocation, possibly more is performed. </dd></dl> -<div class="fragment"><div class="line"><a name="l00367"></a><span class="lineno"> 367</span> {</div><div class="line"><a name="l00368"></a><span class="lineno"> 368</span>  <span class="keywordflow">return</span> <span class="keyword">self</span>.enumerate(std::forward<decltype(tofill)>(tofill), std::forward<decltype(glob)>(glob), std::forward<decltype(filtering)>(filtering), std::forward<decltype(kernelbuffer)>(kernelbuffer));</div><div class="line"><a name="l00369"></a><span class="lineno"> 369</span> }</div></div><!-- fragment --> +<div class="fragment"><div class="line"><a name="l00370"></a><span class="lineno"> 370</span> {</div><div class="line"><a name="l00371"></a><span class="lineno"> 371</span>  <span class="keywordflow">return</span> <span class="keyword">self</span>.enumerate(std::forward<decltype(tofill)>(tofill), std::forward<decltype(glob)>(glob), std::forward<decltype(filtering)>(filtering), std::forward<decltype(kernelbuffer)>(kernelbuffer));</div><div class="line"><a name="l00372"></a><span class="lineno"> 372</span> }</div></div><!-- fragment --> </div> </div> <a id="af31a062639499a79ef5cc8aed16ba65d"></a> @@ -1308,7 +1308,7 @@ For portability, you can only assume that barriers write order for a single hand </div><div class="memdoc"> <p>Create a directory handle creating a randomly named file on a path. The file is opened exclusively with <code>creation::only_if_not_exist</code> so it will never collide with nor overwrite any existing entry.</p> <dl class="section user"><dt>Errors returnable</dt><dd>Any of the values POSIX open() or CreateFile() can return. </dd></dl> -<div class="fragment"><div class="line"><a name="l00336"></a><span class="lineno"> 336</span> {</div><div class="line"><a name="l00337"></a><span class="lineno"> 337</span>  <span class="keywordflow">return</span> <a class="code" href="namespacellfio__v2__xxx.html#ad574b7ae82e4a082a7d5703097d65e92">directory_handle::random_directory</a>(std::forward<decltype(dirpath)>(dirpath), std::forward<decltype(_mode)>(_mode), std::forward<decltype(_caching)>(_caching), std::forward<decltype(flags)>(flags));</div><div class="line"><a name="l00338"></a><span class="lineno"> 338</span> }</div><div class="ttc" id="namespacellfio__v2__xxx_html_ad574b7ae82e4a082a7d5703097d65e92"><div class="ttname"><a href="namespacellfio__v2__xxx.html#ad574b7ae82e4a082a7d5703097d65e92">llfio_v2_xxx::random_directory</a></div><div class="ttdeci">result< directory_handle > random_directory(const path_handle &dirpath, directory_handle::mode _mode=directory_handle::mode::write, directory_handle::caching _caching=directory_handle::caching::temporary, directory_handle::flag flags=directory_handle::flag::none) noexcept</div><div class="ttdef"><b>Definition:</b> directory_handle.hpp:335</div></div> +<div class="fragment"><div class="line"><a name="l00337"></a><span class="lineno"> 337</span> {</div><div class="line"><a name="l00338"></a><span class="lineno"> 338</span>  <span class="keywordflow">return</span> <a class="code" href="namespacellfio__v2__xxx.html#ad574b7ae82e4a082a7d5703097d65e92">directory_handle::random_directory</a>(std::forward<decltype(dirpath)>(dirpath), std::forward<decltype(_mode)>(_mode), std::forward<decltype(_caching)>(_caching), std::forward<decltype(flags)>(flags));</div><div class="line"><a name="l00339"></a><span class="lineno"> 339</span> }</div><div class="ttc" id="namespacellfio__v2__xxx_html_ad574b7ae82e4a082a7d5703097d65e92"><div class="ttname"><a href="namespacellfio__v2__xxx.html#ad574b7ae82e4a082a7d5703097d65e92">llfio_v2_xxx::random_directory</a></div><div class="ttdeci">result< directory_handle > random_directory(const path_handle &dirpath, directory_handle::mode _mode=directory_handle::mode::write, directory_handle::caching _caching=directory_handle::caching::temporary, directory_handle::flag flags=directory_handle::flag::none) noexcept</div><div class="ttdef"><b>Definition:</b> directory_handle.hpp:336</div></div> </div><!-- fragment --> </div> </div> @@ -1801,7 +1801,7 @@ For portability, you can only assume that barriers write order for a single hand </div><div class="memdoc"> <p>Create a directory handle creating the named directory on some path which the OS declares to be suitable for temporary files. Note also that an empty name is equivalent to calling <code>random_file(path_discovery::storage_backed_temporary_files_directory())</code> and the creation parameter is ignored.</p> <dl class="section user"><dt>Errors returnable</dt><dd>Any of the values POSIX open() or CreateFile() can return. </dd></dl> -<div class="fragment"><div class="line"><a name="l00348"></a><span class="lineno"> 348</span> {</div><div class="line"><a name="l00349"></a><span class="lineno"> 349</span>  <span class="keywordflow">return</span> <a class="code" href="namespacellfio__v2__xxx.html#addbdc12d4993a8ee40c105a02a105a61">directory_handle::temp_directory</a>(std::forward<decltype(name)>(name), std::forward<decltype(_mode)>(_mode), std::forward<decltype(_creation)>(_creation), std::forward<decltype(_caching)>(_caching), std::forward<decltype(flags)>(flags));</div><div class="line"><a name="l00350"></a><span class="lineno"> 350</span> }</div><div class="ttc" id="namespacellfio__v2__xxx_html_addbdc12d4993a8ee40c105a02a105a61"><div class="ttname"><a href="namespacellfio__v2__xxx.html#addbdc12d4993a8ee40c105a02a105a61">llfio_v2_xxx::temp_directory</a></div><div class="ttdeci">result< directory_handle > temp_directory(directory_handle::path_view_type name=directory_handle::path_view_type(), directory_handle::mode _mode=directory_handle::mode::write, directory_handle::creation _creation=directory_handle::creation::if_needed, directory_handle::caching _caching=directory_handle::caching::all, directory_handle::flag flags=directory_handle::flag::none) noexcept</div><div class="ttdef"><b>Definition:</b> directory_handle.hpp:347</div></div> +<div class="fragment"><div class="line"><a name="l00350"></a><span class="lineno"> 350</span> {</div><div class="line"><a name="l00351"></a><span class="lineno"> 351</span>  <span class="keywordflow">return</span> <a class="code" href="namespacellfio__v2__xxx.html#addbdc12d4993a8ee40c105a02a105a61">directory_handle::temp_directory</a>(std::forward<decltype(name)>(name), std::forward<decltype(_mode)>(_mode), std::forward<decltype(_creation)>(_creation), std::forward<decltype(_caching)>(_caching), std::forward<decltype(flags)>(flags));</div><div class="line"><a name="l00352"></a><span class="lineno"> 352</span> }</div><div class="ttc" id="namespacellfio__v2__xxx_html_addbdc12d4993a8ee40c105a02a105a61"><div class="ttname"><a href="namespacellfio__v2__xxx.html#addbdc12d4993a8ee40c105a02a105a61">llfio_v2_xxx::temp_directory</a></div><div class="ttdeci">result< directory_handle > temp_directory(directory_handle::path_view_type name=directory_handle::path_view_type(), directory_handle::mode _mode=directory_handle::mode::write, directory_handle::creation _creation=directory_handle::creation::if_needed, directory_handle::caching _caching=directory_handle::caching::all, directory_handle::flag flags=directory_handle::flag::none) noexcept</div><div class="ttdef"><b>Definition:</b> directory_handle.hpp:348</div></div> </div><!-- fragment --> </div> </div> diff --git a/namespacellfio__v2__xxx_1_1utils.html b/namespacellfio__v2__xxx_1_1utils.html index 687125f5..4fb7511b 100644 --- a/namespacellfio__v2__xxx_1_1utils.html +++ b/namespacellfio__v2__xxx_1_1utils.html @@ -88,7 +88,7 @@ $(document).ready(function(){initNavTree('namespacellfio__v2__xxx_1_1utils.html' </div><!--header--> <div class="contents"> -<p>Utility routines often useful when using AFIO. +<p>Utility routines often useful when using LLFIO. <a href="#details">More...</a></p> <table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="nested-classes"></a> @@ -144,7 +144,7 @@ template<class T , class U > </td></tr> <tr class="separator:ae880ebd5681dcf6b700d67fb10b4547e"><td class="memSeparator" colspan="2"> </td></tr> </table> <a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2> -<div class="textblock"><p>Utility routines often useful when using AFIO. </p> +<div class="textblock"><p>Utility routines often useful when using LLFIO. </p> </div><h2 class="groupheader">Function Documentation</h2> <a id="abacefaf60ae391226c4775cf8a61276a"></a> <h2 class="memtitle"><span class="permalink"><a href="#abacefaf60ae391226c4775cf8a61276a">◆ </a></span>drop_filesystem_cache()</h2> diff --git a/namespaces.html b/namespaces.html index a12418a4..3e80cc3a 100644 --- a/namespaces.html +++ b/namespaces.html @@ -86,13 +86,13 @@ $(document).ready(function(){initNavTree('namespaces.html','');}); <div class="contents"> <div class="textblock">Here is a list of all documented namespaces with brief descriptions:</div><div class="directory"> <div class="levels">[detail level <span onclick="javascript:toggleLevel(1);">1</span><span onclick="javascript:toggleLevel(2);">2</span><span onclick="javascript:toggleLevel(3);">3</span>]</div><table class="directory"> -<tr id="row_0_" class="even"><td class="entry"><span style="width:0px;display:inline-block;"> </span><span id="arr_0_" class="arrow" onclick="toggleFolder('0_')">▼</span><span class="icona"><span class="icon">N</span></span><a class="el" href="namespacellfio__v2__xxx.html" target="_self">llfio_v2_xxx</a></td><td class="desc">The AFIO namespace </td></tr> +<tr id="row_0_" class="even"><td class="entry"><span style="width:0px;display:inline-block;"> </span><span id="arr_0_" class="arrow" onclick="toggleFolder('0_')">▼</span><span class="icona"><span class="icon">N</span></span><a class="el" href="namespacellfio__v2__xxx.html" target="_self">llfio_v2_xxx</a></td><td class="desc">The LLFIO namespace </td></tr> <tr id="row_0_0_"><td class="entry"><span style="width:16px;display:inline-block;"> </span><span id="arr_0_0_" class="arrow" onclick="toggleFolder('0_0_')">▼</span><span class="icona"><span class="icon">N</span></span><a class="el" href="namespacellfio__v2__xxx_1_1algorithm.html" target="_self">algorithm</a></td><td class="desc">Collection of file system based algorithms </td></tr> <tr id="row_0_0_0_" class="even"><td class="entry"><span style="width:48px;display:inline-block;"> </span><span class="icona"><span class="icon">N</span></span><a class="el" href="namespacellfio__v2__xxx_1_1algorithm_1_1impl.html" target="_self">impl</a></td><td class="desc">Does not exist in the actual source code, purely here to workaround doxygen limitations </td></tr> <tr id="row_0_0_1_"><td class="entry"><span style="width:48px;display:inline-block;"> </span><span class="icona"><span class="icon">N</span></span><a class="el" href="namespacellfio__v2__xxx_1_1algorithm_1_1shared__fs__mutex.html" target="_self">shared_fs_mutex</a></td><td class="desc">Algorithms for protecting a shared filing system resource from racy modification </td></tr> <tr id="row_0_1_" class="even"><td class="entry"><span style="width:32px;display:inline-block;"> </span><span class="icona"><span class="icon">N</span></span><a class="el" href="namespacellfio__v2__xxx_1_1path__discovery.html" target="_self">path_discovery</a></td><td class="desc">Contains functions used to discover suitable paths for things </td></tr> <tr id="row_0_2_"><td class="entry"><span style="width:32px;display:inline-block;"> </span><span class="icona"><span class="icon">N</span></span><a class="el" href="namespacellfio__v2__xxx_1_1storage__profile.html" target="_self">storage_profile</a></td><td class="desc">YAML databaseable empirical testing of a storage's behaviour </td></tr> -<tr id="row_0_3_" class="even"><td class="entry"><span style="width:32px;display:inline-block;"> </span><span class="icona"><span class="icon">N</span></span><a class="el" href="namespacellfio__v2__xxx_1_1utils.html" target="_self">utils</a></td><td class="desc">Utility routines often useful when using AFIO </td></tr> +<tr id="row_0_3_" class="even"><td class="entry"><span style="width:32px;display:inline-block;"> </span><span class="icona"><span class="icon">N</span></span><a class="el" href="namespacellfio__v2__xxx_1_1utils.html" target="_self">utils</a></td><td class="desc">Utility routines often useful when using LLFIO </td></tr> </table> </div><!-- directory --> </div><!-- contents --> diff --git a/native__handle__type_8hpp.html b/native__handle__type_8hpp.html index 9eb011e4..cdf3190a 100644 --- a/native__handle__type_8hpp.html +++ b/native__handle__type_8hpp.html @@ -101,7 +101,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table> <a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2> diff --git a/path__discovery_8hpp.html b/path__discovery_8hpp.html index 468e0a45..f50b7c84 100644 --- a/path__discovery_8hpp.html +++ b/path__discovery_8hpp.html @@ -103,7 +103,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:namespacellfio__v2__xxx_1_1path__discovery"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx_1_1path__discovery.html">llfio_v2_xxx::path_discovery</a></td></tr> <tr class="memdesc:namespacellfio__v2__xxx_1_1path__discovery"><td class="mdescLeft"> </td><td class="mdescRight">Contains functions used to discover suitable paths for things. <br /></td></tr> diff --git a/path__handle_8hpp.html b/path__handle_8hpp.html index 95e6fab9..8d2563fd 100644 --- a/path__handle_8hpp.html +++ b/path__handle_8hpp.html @@ -106,7 +106,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table><table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="func-members"></a> diff --git a/path__view_8hpp.html b/path__view_8hpp.html index f7eb560d..e48733cf 100644 --- a/path__view_8hpp.html +++ b/path__view_8hpp.html @@ -105,7 +105,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table><table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="func-members"></a> diff --git a/safe__byte__ranges_8hpp.html b/safe__byte__ranges_8hpp.html index 792172fe..b3154407 100644 --- a/safe__byte__ranges_8hpp.html +++ b/safe__byte__ranges_8hpp.html @@ -103,7 +103,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:namespacellfio__v2__xxx_1_1algorithm"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx_1_1algorithm.html">llfio_v2_xxx::algorithm</a></td></tr> <tr class="memdesc:namespacellfio__v2__xxx_1_1algorithm"><td class="mdescLeft"> </td><td class="mdescRight">Collection of file system based algorithms. <br /></td></tr> diff --git a/stat_8hpp.html b/stat_8hpp.html index 26171eb9..1205af19 100644 --- a/stat_8hpp.html +++ b/stat_8hpp.html @@ -101,7 +101,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table> <a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2> diff --git a/statfs_8hpp.html b/statfs_8hpp.html index 492df9a1..6f50eb0c 100644 --- a/statfs_8hpp.html +++ b/statfs_8hpp.html @@ -103,7 +103,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table> <a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2> diff --git a/storage__profile_8hpp.html b/storage__profile_8hpp.html index e8e4b99b..a519494b 100644 --- a/storage__profile_8hpp.html +++ b/storage__profile_8hpp.html @@ -114,7 +114,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:namespacellfio__v2__xxx_1_1storage__profile"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx_1_1storage__profile.html">llfio_v2_xxx::storage_profile</a></td></tr> <tr class="memdesc:namespacellfio__v2__xxx_1_1storage__profile"><td class="mdescLeft"> </td><td class="mdescRight">YAML databaseable empirical testing of a storage's behaviour. <br /></td></tr> diff --git a/structllfio__v2__xxx_1_1error__info.html b/structllfio__v2__xxx_1_1error__info.html index 487adc6a..4e0aff9c 100644 --- a/structllfio__v2__xxx_1_1error__info.html +++ b/structllfio__v2__xxx_1_1error__info.html @@ -88,7 +88,7 @@ $(document).ready(function(){initNavTree('structllfio__v2__xxx_1_1error__info.ht </div><!--header--> <div class="contents"> -<p>The cause of the failure of an operation in AFIO. +<p>The cause of the failure of an operation in LLFIO. <a href="structllfio__v2__xxx_1_1error__info.html#details">More...</a></p> <p><code>#include "status_code.hpp"</code></p> @@ -100,7 +100,7 @@ std::error_code </td><td class="memItemRight" valign="bottom"><b>make_error <tr class="separator:a005a8988d90a60851592b9ce46f43c68"><td class="memSeparator" colspan="2"> </td></tr> </table> <a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2> -<div class="textblock"><p>The cause of the failure of an operation in AFIO. </p> +<div class="textblock"><p>The cause of the failure of an operation in LLFIO. </p> </div><hr/>The documentation for this struct was generated from the following files:<ul> <li>include/llfio/v2.0/status_code.hpp</li> <li>include/llfio/v2.0/<a class="el" href="handle_8hpp.html">handle.hpp</a></li> @@ -88,7 +88,7 @@ $(document).ready(function(){initNavTree('todo.html','');}); <dt><a class="anchor" id="_todo000002"></a>Namespace <a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a> </dt> <dd>TODO FIXME Replace in-memory log with memory map file backed log. </dd> <dt><a class="anchor" id="_todo000004"></a>Class <a class="el" href="classllfio__v2__xxx_1_1algorithm_1_1shared__fs__mutex_1_1atomic__append.html">llfio_v2_xxx::algorithm::shared_fs_mutex::atomic_append</a> </dt> -<dd><p class="startdd">Implement hole punching once I port that code from AFIO v1. </p> +<dd><p class="startdd">Implement hole punching once I port that code from LLFIO v1. </p> <p>Decide on some resolution mechanism for sudden process exit. </p> <p class="enddd">There is a 1 out of 2^64-2 chance of unique id collision. It would be nice if we actually formally checked that our chosen unique id is actually unique. </p> </dd> diff --git a/trivial__vector_8hpp.html b/trivial__vector_8hpp.html index a9f4a668..69cc7a1a 100644 --- a/trivial__vector_8hpp.html +++ b/trivial__vector_8hpp.html @@ -111,7 +111,7 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:namespacellfio__v2__xxx_1_1algorithm"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx_1_1algorithm.html">llfio_v2_xxx::algorithm</a></td></tr> <tr class="memdesc:namespacellfio__v2__xxx_1_1algorithm"><td class="mdescLeft"> </td><td class="mdescRight">Collection of file system based algorithms. <br /></td></tr> diff --git a/utils_8hpp.html b/utils_8hpp.html index 303bc058..4c6888ea 100644 --- a/utils_8hpp.html +++ b/utils_8hpp.html @@ -109,10 +109,10 @@ Classes</h2></td></tr> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="namespaces"></a> Namespaces</h2></td></tr> <tr class="memitem:namespacellfio__v2__xxx"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx.html">llfio_v2_xxx</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO namespace. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO namespace. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:namespacellfio__v2__xxx_1_1utils"><td class="memItemLeft" align="right" valign="top">  </td><td class="memItemRight" valign="bottom"><a class="el" href="namespacellfio__v2__xxx_1_1utils.html">llfio_v2_xxx::utils</a></td></tr> -<tr class="memdesc:namespacellfio__v2__xxx_1_1utils"><td class="mdescLeft"> </td><td class="mdescRight">Utility routines often useful when using AFIO. <br /></td></tr> +<tr class="memdesc:namespacellfio__v2__xxx_1_1utils"><td class="mdescLeft"> </td><td class="mdescRight">Utility routines often useful when using LLFIO. <br /></td></tr> <tr class="separator:"><td class="memSeparator" colspan="2"> </td></tr> </table><table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="func-members"></a> diff --git a/v2_80_2llfio_8hpp.html b/v2_80_2llfio_8hpp.html index 8378adf5..171a30e0 100644 --- a/v2_80_2llfio_8hpp.html +++ b/v2_80_2llfio_8hpp.html @@ -87,7 +87,7 @@ $(document).ready(function(){initNavTree('v2_80_2llfio_8hpp.html','');}); </div><!--header--> <div class="contents"> -<p>The master <em>versioned</em> AFIO include file. All version specific AFIO consuming libraries should include this header only. +<p>The master <em>versioned</em> LLFIO include file. All version specific LLFIO consuming libraries should include this header only. <a href="#details">More...</a></p> <div class="textblock"><code>#include "<a class="el" href="config_8hpp.html">config.hpp</a>"</code><br /> <code>#include "<a class="el" href="handle_8hpp.html">handle.hpp</a>"</code><br /> @@ -133,14 +133,14 @@ Macros</h2></td></tr> <tr class="separator:a7b08237a3cfed4832068a4daa6d6e160"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:a71266556cd079007ccdcd8225f115d87"><td class="memItemLeft" align="right" valign="top"><a id="a71266556cd079007ccdcd8225f115d87"></a> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="v2_80_2llfio_8hpp.html#a71266556cd079007ccdcd8225f115d87">LLFIO_MODULE_NAME</a>   LLFIO_VERSION_GLUE(llfio_v, <a class="el" href="v2_80_2llfio_8hpp.html#a7b08237a3cfed4832068a4daa6d6e160">LLFIO_NAMESPACE_VERSION</a>, )</td></tr> -<tr class="memdesc:a71266556cd079007ccdcd8225f115d87"><td class="mdescLeft"> </td><td class="mdescRight">The AFIO C++ module name. <br /></td></tr> +<tr class="memdesc:a71266556cd079007ccdcd8225f115d87"><td class="mdescLeft"> </td><td class="mdescRight">The LLFIO C++ module name. <br /></td></tr> <tr class="separator:a71266556cd079007ccdcd8225f115d87"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:ae0f8dc3a9d303f90044533d23f6417a8"><td class="memItemLeft" align="right" valign="top"><a id="ae0f8dc3a9d303f90044533d23f6417a8"></a> #define </td><td class="memItemRight" valign="bottom"><b>LLFIO_INCLUDE_ALL</b></td></tr> <tr class="separator:ae0f8dc3a9d303f90044533d23f6417a8"><td class="memSeparator" colspan="2"> </td></tr> </table> <a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2> -<div class="textblock"><p>The master <em>versioned</em> AFIO include file. All version specific AFIO consuming libraries should include this header only. </p> +<div class="textblock"><p>The master <em>versioned</em> LLFIO include file. All version specific LLFIO consuming libraries should include this header only. </p> </div></div><!-- contents --> </div><!-- doc-content --> <!-- start footer part --> diff --git a/version_8hpp.html b/version_8hpp.html index b848b197..8672e319 100644 --- a/version_8hpp.html +++ b/version_8hpp.html @@ -87,7 +87,7 @@ $(document).ready(function(){initNavTree('version_8hpp.html','');}); </div><!--header--> <div class="contents"> -<p>Controls the version of AFIO for cmake, shared library and C++ namespace mangling. +<p>Controls the version of LLFIO for cmake, shared library and C++ namespace mangling. <a href="#details">More...</a></p> <table class="memberdecls"> <tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="define-members"></a> @@ -110,10 +110,10 @@ Macros</h2></td></tr> <tr class="separator:ga18295c2601f9e6cb9e759d57fa0d8ab4"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:gaadd4f1f9d1a5c77c3b40d9e1b759b706"><td class="memItemLeft" align="right" valign="top"> #define </td><td class="memItemRight" valign="bottom"><a class="el" href="group__config.html#gaadd4f1f9d1a5c77c3b40d9e1b759b706">LLFIO_UNSTABLE_VERSION</a></td></tr> -<tr class="memdesc:gaadd4f1f9d1a5c77c3b40d9e1b759b706"><td class="mdescLeft"> </td><td class="mdescRight">Defined between stable releases of AFIO. It means the inline namespace will be permuted per-commit to ensure ABI uniqueness. <br /></td></tr> +<tr class="memdesc:gaadd4f1f9d1a5c77c3b40d9e1b759b706"><td class="mdescLeft"> </td><td class="mdescRight">Defined between stable releases of LLFIO. It means the inline namespace will be permuted per-commit to ensure ABI uniqueness. <br /></td></tr> <tr class="separator:gaadd4f1f9d1a5c77c3b40d9e1b759b706"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:aadba5400c27b35d85067c431cfd9b0e6"><td class="memItemLeft" align="right" valign="top"><a id="aadba5400c27b35d85067c431cfd9b0e6"></a> -#define </td><td class="memItemRight" valign="bottom"><b>LLFIO_VERSION_GLUE2</b>(a, b, c)   a ## b ## c</td></tr> +#define </td><td class="memItemRight" valign="bottom"><b>LLFIO_VERSION_GLUE2</b>(a, b, c)   a##b##c</td></tr> <tr class="separator:aadba5400c27b35d85067c431cfd9b0e6"><td class="memSeparator" colspan="2"> </td></tr> <tr class="memitem:a699beb5138cc8f2a2df12d833e4d96be"><td class="memItemLeft" align="right" valign="top"><a id="a699beb5138cc8f2a2df12d833e4d96be"></a> #define </td><td class="memItemRight" valign="bottom"><b>LLFIO_VERSION_GLUE</b>(a, b, c)   LLFIO_VERSION_GLUE2(a, b, c)</td></tr> @@ -131,7 +131,7 @@ Macros</h2></td></tr> <tr class="separator:a7b08237a3cfed4832068a4daa6d6e160"><td class="memSeparator" colspan="2"> </td></tr> </table> <a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2> -<div class="textblock"><p>Controls the version of AFIO for cmake, shared library and C++ namespace mangling. </p> +<div class="textblock"><p>Controls the version of LLFIO for cmake, shared library and C++ namespace mangling. </p> </div></div><!-- contents --> </div><!-- doc-content --> <!-- start footer part --> |