Welcome to mirror list, hosted at ThFree Co, Russian Federation.

github.com/windirstat/llfio.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'classllfio__v2__xxx_1_1path__handle.html')
-rw-r--r--classllfio__v2__xxx_1_1path__handle.html154
1 files changed, 54 insertions, 100 deletions
diff --git a/classllfio__v2__xxx_1_1path__handle.html b/classllfio__v2__xxx_1_1path__handle.html
index 6e4b511d..e22ec409 100644
--- a/classllfio__v2__xxx_1_1path__handle.html
+++ b/classllfio__v2__xxx_1_1path__handle.html
@@ -134,29 +134,6 @@ using&#160;</td><td class="memItemRight" valign="bottom"><b>flag</b> = handle::f
using&#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="classllfio__v2__xxx_1_1path__handle.html#a6f2c51636f17ae97255106d37ef4187c">path_view_type</a> = <a class="el" href="classllfio__v2__xxx_1_1path__view.html">path_view</a></td></tr>
<tr class="memdesc:a6f2c51636f17ae97255106d37ef4187c"><td class="mdescLeft">&#160;</td><td class="mdescRight">The path view type used by this handle. <br /></td></tr>
<tr class="separator:a6f2c51636f17ae97255106d37ef4187c"><td class="memSeparator" colspan="2">&#160;</td></tr>
-<tr class="memitem:a5929f46f42112bd805ab5001bfbf9d2a"><td class="memItemLeft" align="right" valign="top">enum &#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2a">bitfield__flag</a> : unsigned { <br />
-&#160;&#160;<a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a> = 0,
-<a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa334c4a4c42fdb79d7ebc3e73b517e6f8">none</a> = 2,
-<a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa334c4a4c42fdb79d7ebc3e73b517e6f8">none</a> = 1,
-<a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">unlink_on_first_close</a> = 1U &lt;&lt; 0U,
-<br />
-&#160;&#160;<a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aad624bee14c8a425153440c17bd2d893d">disable_safety_barriers</a> = 1U &lt;&lt; 2U,
-<a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">disable_safety_unlinks</a> = 1U &lt;&lt; 3U,
-<a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">disable_prefetching</a> = 1U &lt;&lt; 4U,
-<a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">maximum_prefetching</a> = 1U &lt;&lt; 5U,
-<br />
-&#160;&#160;<a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">win_disable_unlink_emulation</a> = 1U &lt;&lt; 24U,
-<a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">win_disable_sparse_file_creation</a> = 1U &lt;&lt; 25U,
-<a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa49d1f07791f8f6d711df222027abe322">disable_parallelism</a> = 1U &lt;&lt; 26U,
-<a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa3375a48d9e197ee058d14e4df6c8b681">win_create_case_sensitive_directory</a> = 1U &lt;&lt; 27U,
-<br />
-&#160;&#160;<a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">overlapped</a> = 1U &lt;&lt; 28U,
-<a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">byte_lock_insanity</a> = 1U &lt;&lt; 29U,
-<a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">anonymous_inode</a> = 1U &lt;&lt; 30U
-<br />
- }<tr class="memdesc:a5929f46f42112bd805ab5001bfbf9d2a"><td class="mdescLeft">&#160;</td><td class="mdescRight">Bitwise flags which can be specified. <a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2a">More...</a><br /></td></tr>
-</td></tr>
-<tr class="separator:a5929f46f42112bd805ab5001bfbf9d2a"><td class="memSeparator" colspan="2">&#160;</td></tr>
</table><table class="memberdecls">
<tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="pub-methods"></a>
Public Member Functions</h2></td></tr>
@@ -198,6 +175,12 @@ virtual result&lt; void &gt;&#160;</td><td class="memItemRight" valign="bottom">
<tr class="separator:ad397dbfc5cd5eb53f203a2c1c9540a2e"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:ae260bf811da1b17c142f51fbb53476bf"><td class="memItemLeft" align="right" valign="top">result&lt; <a class="el" href="classllfio__v2__xxx_1_1path__handle.html">path_handle</a> &gt;&#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="classllfio__v2__xxx_1_1path__handle.html#ae260bf811da1b17c142f51fbb53476bf">clone</a> () const noexcept</td></tr>
<tr class="separator:ae260bf811da1b17c142f51fbb53476bf"><td class="memSeparator" colspan="2">&#160;</td></tr>
+<tr class="memitem:ac5222904f116c9beb0515a4a5aa850bf"><td class="memItemLeft" align="right" valign="top">&#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="classllfio__v2__xxx_1_1handle.html#ac5222904f116c9beb0515a4a5aa850bf">QUICKCPPLIB_BITFIELD_BEGIN</a> (flag)</td></tr>
+<tr class="memdesc:ac5222904f116c9beb0515a4a5aa850bf"><td class="mdescLeft">&#160;</td><td class="mdescRight">Bitwise flags which can be specified. <a href="#ac5222904f116c9beb0515a4a5aa850bf">More...</a><br /></td></tr>
+<tr class="separator:ac5222904f116c9beb0515a4a5aa850bf"><td class="memSeparator" colspan="2">&#160;</td></tr>
+<tr class="memitem:aa7e9bedf8c7a4c4a79a644a6e1857ee4"><td class="memItemLeft" align="right" valign="top"><a id="aa7e9bedf8c7a4c4a79a644a6e1857ee4"></a>
+&#160;</td><td class="memItemRight" valign="bottom"><b>QUICKCPPLIB_BITFIELD_END</b> (flag)</td></tr>
+<tr class="separator:aa7e9bedf8c7a4c4a79a644a6e1857ee4"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:a4716696b8700953889006251e0678aa4"><td class="memItemLeft" align="right" valign="top"><a id="a4716696b8700953889006251e0678aa4"></a>
void&#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="classllfio__v2__xxx_1_1handle.html#a4716696b8700953889006251e0678aa4">swap</a> (<a class="el" href="classllfio__v2__xxx_1_1handle.html">handle</a> &amp;o) noexcept</td></tr>
<tr class="memdesc:a4716696b8700953889006251e0678aa4"><td class="mdescLeft">&#160;</td><td class="mdescRight">Swap with another instance. <br /></td></tr>
@@ -297,7 +280,7 @@ Static Public Member Functions</h2></td></tr>
<tr class="heading"><td colspan="2"><h2 class="groupheader"><a name="pro-attribs"></a>
Protected Attributes</h2></td></tr>
<tr class="memitem:affb091ded80ffde7c0c3854e2abc52fd"><td class="memItemLeft" align="right" valign="top"><a id="affb091ded80ffde7c0c3854e2abc52fd"></a>
-<a class="el" href="classllfio__v2__xxx_1_1handle.html#aecd3a7db6cee3aec07d32fe6f99e6852">caching</a>&#160;</td><td class="memItemRight" valign="bottom"><b>_caching</b> {<a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa334c4a4c42fdb79d7ebc3e73b517e6f8">caching::none</a>}</td></tr>
+<a class="el" href="classllfio__v2__xxx_1_1handle.html#aecd3a7db6cee3aec07d32fe6f99e6852">caching</a>&#160;</td><td class="memItemRight" valign="bottom"><b>_caching</b> {<a class="el" href="classllfio__v2__xxx_1_1handle.html#aecd3a7db6cee3aec07d32fe6f99e6852a334c4a4c42fdb79d7ebc3e73b517e6f8">caching::none</a>}</td></tr>
<tr class="separator:affb091ded80ffde7c0c3854e2abc52fd"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:ad758cf1eb2e0b4c63583eab05e7f6820"><td class="memItemLeft" align="right" valign="top"><a id="ad758cf1eb2e0b4c63583eab05e7f6820"></a>
flag&#160;</td><td class="memItemRight" valign="bottom"><b>_flags</b> {flag::none}</td></tr>
@@ -314,81 +297,7 @@ class&#160;</td><td class="memItemRight" valign="bottom"><b>directory_handle</b>
</table>
<a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2>
<div class="textblock"><p>A handle to somewhere originally identified by a path on the filing system. Typically used as the lightest weight handle to some location on the filing system which may unpredictably relocate over time. This handle is thus an <em>anchor</em> to a subset island of the filing system, free of any race conditions introduced by third party changes to any part of the path leading to that island. </p>
-</div><h2 class="groupheader">Member Enumeration Documentation</h2>
-<a id="a5929f46f42112bd805ab5001bfbf9d2a"></a>
-<h2 class="memtitle"><span class="permalink"><a href="#a5929f46f42112bd805ab5001bfbf9d2a">&#9670;&nbsp;</a></span>bitfield__flag</h2>
-
-<div class="memitem">
-<div class="memproto">
-<table class="mlabels">
- <tr>
- <td class="mlabels-left">
- <table class="memname">
- <tr>
- <td class="memname">enum <a class="el" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2a">llfio_v2_xxx::handle::bitfield__flag</a> : unsigned</td>
- </tr>
- </table>
- </td>
- <td class="mlabels-right">
-<span class="mlabels"><span class="mlabel">inherited</span></span> </td>
- </tr>
-</table>
-</div><div class="memdoc">
-
-<p>Bitwise flags which can be specified. </p>
-<table class="fieldtable">
-<tr><th colspan="2">Enumerator</th></tr><tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298"></a>none&#160;</td><td class="fielddoc"><p>No flags. </p>
-</td></tr>
-<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa334c4a4c42fdb79d7ebc3e73b517e6f8"></a>none&#160;</td><td class="fielddoc"><p>No ability to read or write anything, but can synchronise (SYNCHRONIZE or 0) </p>
-</td></tr>
-<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa334c4a4c42fdb79d7ebc3e73b517e6f8"></a>none&#160;</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>disable_safety_barriers</code> can be used here. </p>
-</td></tr>
-<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962"></a>unlink_on_first_close&#160;</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="a5929f46f42112bd805ab5001bfbf9d2aad624bee14c8a425153440c17bd2d893d"></a>disable_safety_barriers&#160;</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_barriers </p>
-</td></tr>
-<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b"></a>disable_safety_unlinks&#160;</td><td class="fielddoc"><p><code>file_handle::unlink()</code> could accidentally delete the wrong file if someone has renamed the open file handle since the time it was opened. To prevent this occuring, where the OS doesn't provide race free unlink-by-open-handle we compare the inode of the path we are about to unlink with that of the open handle before unlinking. </p><dl class="section warning"><dt>Warning</dt><dd>This does not prevent races where in between the time of checking the inode and executing the unlink a third party changes the item about to be unlinked. Only operating systems with a true race-free unlink syscall are race free. </dd></dl>
-</td></tr>
-<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3"></a>disable_prefetching&#160;</td><td class="fielddoc"><p>Ask the OS to disable prefetching of data. This can improve random i/o performance. </p>
-</td></tr>
-<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0"></a>maximum_prefetching&#160;</td><td class="fielddoc"><p>Ask the OS to maximise prefetching of data, possibly prefetching the entire file into kernel cache. This can improve sequential i/o performance. </p>
-</td></tr>
-<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c"></a>win_disable_unlink_emulation&#160;</td><td class="fielddoc"><p>See the documentation for <code>unlink_on_first_close</code> </p>
-</td></tr>
-<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0"></a>win_disable_sparse_file_creation&#160;</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, 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="a5929f46f42112bd805ab5001bfbf9d2aa49d1f07791f8f6d711df222027abe322"></a>disable_parallelism&#160;</td><td class="fielddoc"><p>Filesystems tend to be embarrassingly parallel for operations performed to different inodes. Where LLFIO performs i/o to multiple inodes at a time, it will use OpenMP or the Parallelism or Concurrency standard library extensions to usually complete the operation in constant rather than linear time. If you don't want this default, you can disable default using this flag. </p>
-</td></tr>
-<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa3375a48d9e197ee058d14e4df6c8b681"></a>win_create_case_sensitive_directory&#160;</td><td class="fielddoc"><p>Microsoft Windows NTFS has the option, when creating a directory, to set whether leafname lookup will be case sensitive. This is the only way of getting exact POSIX semantics on Windows without resorting to editing the system registry, however it also affects all code doing lookups within that directory, so we must default it to off. </p>
-</td></tr>
-<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a"></a>overlapped&#160;</td><td class="fielddoc"><p>On Windows, create any new handles with OVERLAPPED semantics. </p>
-</td></tr>
-<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59"></a>byte_lock_insanity&#160;</td><td class="fielddoc"><p>Using insane POSIX byte range locks. </p>
-</td></tr>
-<tr><td class="fieldname"><a id="a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d"></a>anonymous_inode&#160;</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>&#160; {</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>&#160; <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aae6fb35b3d125d5d76bbef95b1d804298">none</a> = 0, <span class="comment">//!&lt; No flags</span></div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span>&#160;<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>&#160;<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>&#160;<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>&#160;<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>&#160;<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>&#160;<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>&#160;<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>&#160;<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>&#160;<span class="comment"> */</span></div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span>&#160; <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">unlink_on_first_close</a> = 1U &lt;&lt; 0U,</div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span>&#160;<span class="comment"></span></div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span>&#160;<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>&#160;<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>&#160;<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>&#160;<span class="comment"> caching modes specified below:</span></div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span>&#160;<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>&#160;<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>&#160;<span class="comment"></span></div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span>&#160;<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>&#160;<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>&#160;<span class="comment"> * On the parent directory on file close.</span></div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span>&#160;<span class="comment"></span></div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span>&#160;<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>&#160;<span class="comment"> * caching::none</span></div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span>&#160;<span class="comment"> * caching::reads</span></div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span>&#160;<span class="comment"> * caching::reads_and_metadata</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span>&#160;<span class="comment"> * caching::safety_barriers</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span>&#160;<span class="comment"> */</span></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span>&#160; <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aad624bee14c8a425153440c17bd2d893d">disable_safety_barriers</a> = 1U &lt;&lt; 2U,<span class="comment"></span></div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span>&#160;<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>&#160;<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>&#160;<span class="comment"> where the OS doesn&#39;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>&#160;<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>&#160;<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>&#160;<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>&#160;<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>&#160;<span class="comment"> */</span></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span>&#160; <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa5832b1ccb7f83ea61bf9e7f237ea481b">disable_safety_unlinks</a> = 1U &lt;&lt; 3U,<span class="comment"></span></div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span>&#160;<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>&#160;<span class="comment"> i/o performance.</span></div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span>&#160;<span class="comment"> */</span></div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span>&#160; <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">disable_prefetching</a> = 1U &lt;&lt; 4U,<span class="comment"></span></div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span>&#160;<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>&#160;<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>&#160;<span class="comment"> */</span></div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span>&#160; <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaf131856fed08b53ec642fbdc6d063de0">maximum_prefetching</a> = 1U &lt;&lt; 5U,</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span>&#160;</div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span>&#160; <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">win_disable_unlink_emulation</a> = 1U &lt;&lt; 24U, <span class="comment">//!&lt; See the documentation for `unlink_on_first_close`</span></div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span>&#160;<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>&#160;<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>&#160;<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>&#160;<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>&#160;<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>&#160;<span class="comment"> was set to.</span></div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span>&#160;<span class="comment"></span></div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span>&#160;<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>&#160;<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>&#160;<span class="comment"> explicitly &quot;opt in&quot; to extents-based storage.</span></div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span>&#160;<span class="comment"></span></div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span>&#160;<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>&#160;<span class="comment"> extents-based storage for any empty file it creates. If you don&#39;t want this, you</span></div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span>&#160;<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>&#160;<span class="comment"> */</span></div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span>&#160; <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">win_disable_sparse_file_creation</a> = 1U &lt;&lt; 25U,<span class="comment"></span></div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span>&#160;<span class="comment"> /*! Filesystems tend to be embarrassingly parallel for operations performed to different</span></div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span>&#160;<span class="comment"> inodes. Where LLFIO performs i/o to multiple inodes at a time, it will use OpenMP or</span></div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span>&#160;<span class="comment"> the Parallelism or Concurrency standard library extensions to usually complete the</span></div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span>&#160;<span class="comment"> operation in constant rather than linear time. If you don&#39;t want this default, you can</span></div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span>&#160;<span class="comment"> disable default using this flag.</span></div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span>&#160;<span class="comment"> */</span></div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span>&#160; <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa49d1f07791f8f6d711df222027abe322">disable_parallelism</a> = 1U &lt;&lt; 26U,<span class="comment"></span></div><div class="line"><a name="l00171"></a><span class="lineno"> 171</span>&#160;<span class="comment"> /*! Microsoft Windows NTFS has the option, when creating a directory, to set whether</span></div><div class="line"><a name="l00172"></a><span class="lineno"> 172</span>&#160;<span class="comment"> leafname lookup will be case sensitive. This is the only way of getting exact POSIX</span></div><div class="line"><a name="l00173"></a><span class="lineno"> 173</span>&#160;<span class="comment"> semantics on Windows without resorting to editing the system registry, however it also</span></div><div class="line"><a name="l00174"></a><span class="lineno"> 174</span>&#160;<span class="comment"> affects all code doing lookups within that directory, so we must default it to off.</span></div><div class="line"><a name="l00175"></a><span class="lineno"> 175</span>&#160;<span class="comment"> */</span></div><div class="line"><a name="l00176"></a><span class="lineno"> 176</span>&#160; <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa3375a48d9e197ee058d14e4df6c8b681">win_create_case_sensitive_directory</a> = 1U &lt;&lt; 27U,</div><div class="line"><a name="l00177"></a><span class="lineno"> 177</span>&#160;</div><div class="line"><a name="l00178"></a><span class="lineno"> 178</span>&#160; <span class="comment">// NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!</span></div><div class="line"><a name="l00179"></a><span class="lineno"> 179</span>&#160;</div><div class="line"><a name="l00180"></a><span class="lineno"> 180</span>&#160; <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">overlapped</a> = 1U &lt;&lt; 28U, <span class="comment">//!&lt; On Windows, create any new handles with OVERLAPPED semantics</span></div><div class="line"><a name="l00181"></a><span class="lineno"> 181</span>&#160;<span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">byte_lock_insanity</a> = 1U &lt;&lt; 29U, <span class="comment">//!&lt; Using insane POSIX byte range locks</span></div><div class="line"><a name="l00182"></a><span class="lineno"> 182</span>&#160;<span class="comment"></span> <a class="code" href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa07122ea63cdc5b2c07e764d95a816d3d">anonymous_inode</a> = 1U &lt;&lt; 30U <span class="comment">//!&lt; This is an inode created with no representation on the filing system</span></div><div class="line"><a name="l00183"></a><span class="lineno"> 183</span>&#160;<span class="comment"></span> } QUICKCPPLIB_BITFIELD_END(flag);</div><div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa3375a48d9e197ee058d14e4df6c8b681"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa3375a48d9e197ee058d14e4df6c8b681">llfio_v2_xxx::handle::win_create_case_sensitive_directory</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:176</div></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:182</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_a5929f46f42112bd805ab5001bfbf9d2aa49d1f07791f8f6d711df222027abe322"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa49d1f07791f8f6d711df222027abe322">llfio_v2_xxx::handle::disable_parallelism</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:170</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>
-<div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aab099987c48559cca2de094c74ffc702a">llfio_v2_xxx::handle::overlapped</a></div><div class="ttdoc">On Windows, create any new handles with OVERLAPPED semantics. </div><div class="ttdef"><b>Definition:</b> handle.hpp:180</div></div>
-<div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa4557d4caa81561875089ae5f819fb2c3">llfio_v2_xxx::handle::disable_prefetching</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:141</div></div>
-<div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa6aa77c9bac6dd95b83f8d278f0e5fa59">llfio_v2_xxx::handle::byte_lock_insanity</a></div><div class="ttdoc">Using insane POSIX byte range locks. </div><div class="ttdef"><b>Definition:</b> handle.hpp:181</div></div>
-<div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aa72328d49ab1e37950ff31891b47a6962">llfio_v2_xxx::handle::unlink_on_first_close</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:109</div></div>
-<div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aacf17c790c4b3af070b11bc5b75911f9c">llfio_v2_xxx::handle::win_disable_unlink_emulation</a></div><div class="ttdoc">See the documentation for unlink_on_first_close </div><div class="ttdef"><b>Definition:</b> handle.hpp:147</div></div>
-<div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aad624bee14c8a425153440c17bd2d893d"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aad624bee14c8a425153440c17bd2d893d">llfio_v2_xxx::handle::disable_safety_barriers</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:128</div></div>
-<div class="ttc" id="classllfio__v2__xxx_1_1handle_html_a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0"><div class="ttname"><a href="classllfio__v2__xxx_1_1handle.html#a5929f46f42112bd805ab5001bfbf9d2aaafd26e37b4a783bd9814549fb4ff6cd0">llfio_v2_xxx::handle::win_disable_sparse_file_creation</a></div><div class="ttdef"><b>Definition:</b> handle.hpp:163</div></div>
-</div><!-- fragment -->
-</div>
-</div>
-<h2 class="groupheader">Member Function Documentation</h2>
+</div><h2 class="groupheader">Member Function Documentation</h2>
<a id="ae260bf811da1b17c142f51fbb53476bf"></a>
<h2 class="memtitle"><span class="permalink"><a href="#ae260bf811da1b17c142f51fbb53476bf">&#9670;&nbsp;</a></span>clone()</h2>
@@ -440,7 +349,7 @@ class&#160;</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 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&lt;T&gt;</code> for a handle adapter which makes use of that.</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::cached_parent_handle_adapter&lt;T&gt;</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>
@@ -517,6 +426,51 @@ class&#160;</td><td class="memItemRight" valign="bottom"><b>directory_handle</b>
</div><!-- fragment -->
</div>
</div>
+<a id="ac5222904f116c9beb0515a4a5aa850bf"></a>
+<h2 class="memtitle"><span class="permalink"><a href="#ac5222904f116c9beb0515a4a5aa850bf">&#9670;&nbsp;</a></span>QUICKCPPLIB_BITFIELD_BEGIN()</h2>
+
+<div class="memitem">
+<div class="memproto">
+<table class="mlabels">
+ <tr>
+ <td class="mlabels-left">
+ <table class="memname">
+ <tr>
+ <td class="memname">llfio_v2_xxx::handle::QUICKCPPLIB_BITFIELD_BEGIN </td>
+ <td>(</td>
+ <td class="paramtype">flag&#160;</td>
+ <td class="paramname"></td><td>)</td>
+ <td></td>
+ </tr>
+ </table>
+ </td>
+ <td class="mlabels-right">
+<span class="mlabels"><span class="mlabel">inline</span><span class="mlabel">inherited</span></span> </td>
+ </tr>
+</table>
+</div><div class="memdoc">
+
+<p>Bitwise flags which can be specified. </p>
+<p>&lt; No flags </p><pre class="fragment">Unlinks the file on handle close. On POSIX, this simply unlinks whatever is pointed
+</pre><p> 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>
+<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_barriers</p>
+<p><code>file_handle::unlink()</code> could accidentally delete the wrong file if someone has renamed the open file handle since the time it was opened. To prevent this occuring, where the OS doesn't provide race free unlink-by-open-handle we compare the inode of the path we are about to unlink with that of the open handle before unlinking. </p><dl class="section warning"><dt>Warning</dt><dd>This does not prevent races where in between the time of checking the inode and executing the unlink a third party changes the item about to be unlinked. Only operating systems with a true race-free unlink syscall are race free.</dd></dl>
+<p>Ask the OS to disable prefetching of data. This can improve random i/o performance.</p>
+<p>Ask the OS to maximise prefetching of data, possibly prefetching the entire file into kernel cache. This can improve sequential i/o performance.</p>
+<p>&lt; See the documentation for <code>unlink_on_first_close</code> </p><pre class="fragment">Microsoft Windows NTFS, having been created in the late 1980s, did not originally
+</pre><p> 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, 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>
+<p>Filesystems tend to be embarrassingly parallel for operations performed to different inodes. Where LLFIO performs i/o to multiple inodes at a time, it will use OpenMP or the Parallelism or Concurrency standard library extensions to usually complete the operation in constant rather than linear time. If you don't want this default, you can disable default using this flag.</p>
+<p>Microsoft Windows NTFS has the option, when creating a directory, to set whether leafname lookup will be case sensitive. This is the only way of getting exact POSIX semantics on Windows without resorting to editing the system registry, however it also affects all code doing lookups within that directory, so we must default it to off.</p>
+<p>&lt; On Windows, create any new handles with OVERLAPPED semantics</p>
+<p>&lt; Using insane POSIX byte range locks</p>
+<p>&lt; This is an inode created with no representation on the filing system </p>
+<div class="fragment"><div class="line"><a name="l00098"></a><span class="lineno"> 98</span>&#160; {</div><div class="line"><a name="l00099"></a><span class="lineno"> 99</span>&#160; none = 0, <span class="comment">//!&lt; No flags</span></div><div class="line"><a name="l00100"></a><span class="lineno"> 100</span>&#160;<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>&#160;<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>&#160;<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>&#160;<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>&#160;<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>&#160;<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>&#160;<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>&#160;<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>&#160;<span class="comment"> */</span></div><div class="line"><a name="l00109"></a><span class="lineno"> 109</span>&#160; unlink_on_first_close = 1U &lt;&lt; 0U,</div><div class="line"><a name="l00110"></a><span class="lineno"> 110</span>&#160;<span class="comment"></span></div><div class="line"><a name="l00111"></a><span class="lineno"> 111</span>&#160;<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>&#160;<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>&#160;<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>&#160;<span class="comment"> caching modes specified below:</span></div><div class="line"><a name="l00115"></a><span class="lineno"> 115</span>&#160;<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>&#160;<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>&#160;<span class="comment"></span></div><div class="line"><a name="l00118"></a><span class="lineno"> 118</span>&#160;<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>&#160;<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>&#160;<span class="comment"> * On the parent directory on file close.</span></div><div class="line"><a name="l00121"></a><span class="lineno"> 121</span>&#160;<span class="comment"></span></div><div class="line"><a name="l00122"></a><span class="lineno"> 122</span>&#160;<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>&#160;<span class="comment"> * caching::none</span></div><div class="line"><a name="l00124"></a><span class="lineno"> 124</span>&#160;<span class="comment"> * caching::reads</span></div><div class="line"><a name="l00125"></a><span class="lineno"> 125</span>&#160;<span class="comment"> * caching::reads_and_metadata</span></div><div class="line"><a name="l00126"></a><span class="lineno"> 126</span>&#160;<span class="comment"> * caching::safety_barriers</span></div><div class="line"><a name="l00127"></a><span class="lineno"> 127</span>&#160;<span class="comment"> */</span></div><div class="line"><a name="l00128"></a><span class="lineno"> 128</span>&#160; disable_safety_barriers = 1U &lt;&lt; 2U,<span class="comment"></span></div><div class="line"><a name="l00129"></a><span class="lineno"> 129</span>&#160;<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>&#160;<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>&#160;<span class="comment"> where the OS doesn&#39;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>&#160;<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>&#160;<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>&#160;<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>&#160;<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>&#160;<span class="comment"> */</span></div><div class="line"><a name="l00137"></a><span class="lineno"> 137</span>&#160; disable_safety_unlinks = 1U &lt;&lt; 3U,<span class="comment"></span></div><div class="line"><a name="l00138"></a><span class="lineno"> 138</span>&#160;<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>&#160;<span class="comment"> i/o performance.</span></div><div class="line"><a name="l00140"></a><span class="lineno"> 140</span>&#160;<span class="comment"> */</span></div><div class="line"><a name="l00141"></a><span class="lineno"> 141</span>&#160; disable_prefetching = 1U &lt;&lt; 4U,<span class="comment"></span></div><div class="line"><a name="l00142"></a><span class="lineno"> 142</span>&#160;<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>&#160;<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>&#160;<span class="comment"> */</span></div><div class="line"><a name="l00145"></a><span class="lineno"> 145</span>&#160; maximum_prefetching = 1U &lt;&lt; 5U,</div><div class="line"><a name="l00146"></a><span class="lineno"> 146</span>&#160;</div><div class="line"><a name="l00147"></a><span class="lineno"> 147</span>&#160; win_disable_unlink_emulation = 1U &lt;&lt; 24U, <span class="comment">//!&lt; See the documentation for `unlink_on_first_close`</span></div><div class="line"><a name="l00148"></a><span class="lineno"> 148</span>&#160;<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>&#160;<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>&#160;<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>&#160;<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>&#160;<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>&#160;<span class="comment"> was set to.</span></div><div class="line"><a name="l00154"></a><span class="lineno"> 154</span>&#160;<span class="comment"></span></div><div class="line"><a name="l00155"></a><span class="lineno"> 155</span>&#160;<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>&#160;<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>&#160;<span class="comment"> explicitly &quot;opt in&quot; to extents-based storage.</span></div><div class="line"><a name="l00158"></a><span class="lineno"> 158</span>&#160;<span class="comment"></span></div><div class="line"><a name="l00159"></a><span class="lineno"> 159</span>&#160;<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>&#160;<span class="comment"> extents-based storage for any empty file it creates. If you don&#39;t want this, you</span></div><div class="line"><a name="l00161"></a><span class="lineno"> 161</span>&#160;<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>&#160;<span class="comment"> */</span></div><div class="line"><a name="l00163"></a><span class="lineno"> 163</span>&#160; win_disable_sparse_file_creation = 1U &lt;&lt; 25U,<span class="comment"></span></div><div class="line"><a name="l00164"></a><span class="lineno"> 164</span>&#160;<span class="comment"> /*! Filesystems tend to be embarrassingly parallel for operations performed to different</span></div><div class="line"><a name="l00165"></a><span class="lineno"> 165</span>&#160;<span class="comment"> inodes. Where LLFIO performs i/o to multiple inodes at a time, it will use OpenMP or</span></div><div class="line"><a name="l00166"></a><span class="lineno"> 166</span>&#160;<span class="comment"> the Parallelism or Concurrency standard library extensions to usually complete the</span></div><div class="line"><a name="l00167"></a><span class="lineno"> 167</span>&#160;<span class="comment"> operation in constant rather than linear time. If you don&#39;t want this default, you can</span></div><div class="line"><a name="l00168"></a><span class="lineno"> 168</span>&#160;<span class="comment"> disable default using this flag.</span></div><div class="line"><a name="l00169"></a><span class="lineno"> 169</span>&#160;<span class="comment"> */</span></div><div class="line"><a name="l00170"></a><span class="lineno"> 170</span>&#160; disable_parallelism = 1U &lt;&lt; 26U,<span class="comment"></span></div><div class="line"><a name="l00171"></a><span class="lineno"> 171</span>&#160;<span class="comment"> /*! Microsoft Windows NTFS has the option, when creating a directory, to set whether</span></div><div class="line"><a name="l00172"></a><span class="lineno"> 172</span>&#160;<span class="comment"> leafname lookup will be case sensitive. This is the only way of getting exact POSIX</span></div><div class="line"><a name="l00173"></a><span class="lineno"> 173</span>&#160;<span class="comment"> semantics on Windows without resorting to editing the system registry, however it also</span></div><div class="line"><a name="l00174"></a><span class="lineno"> 174</span>&#160;<span class="comment"> affects all code doing lookups within that directory, so we must default it to off.</span></div><div class="line"><a name="l00175"></a><span class="lineno"> 175</span>&#160;<span class="comment"> */</span></div><div class="line"><a name="l00176"></a><span class="lineno"> 176</span>&#160; win_create_case_sensitive_directory = 1U &lt;&lt; 27U,</div><div class="line"><a name="l00177"></a><span class="lineno"> 177</span>&#160;</div><div class="line"><a name="l00178"></a><span class="lineno"> 178</span>&#160; <span class="comment">// NOTE: IF UPDATING THIS UPDATE THE std::ostream PRINTER BELOW!!!</span></div><div class="line"><a name="l00179"></a><span class="lineno"> 179</span>&#160;</div><div class="line"><a name="l00180"></a><span class="lineno"> 180</span>&#160; overlapped = 1U &lt;&lt; 28U, <span class="comment">//!&lt; On Windows, create any new handles with OVERLAPPED semantics</span></div><div class="line"><a name="l00181"></a><span class="lineno"> 181</span>&#160;<span class="comment"></span> byte_lock_insanity = 1U &lt;&lt; 29U, <span class="comment">//!&lt; Using insane POSIX byte range locks</span></div><div class="line"><a name="l00182"></a><span class="lineno"> 182</span>&#160;<span class="comment"></span> anonymous_inode = 1U &lt;&lt; 30U <span class="comment">//!&lt; This is an inode created with no representation on the filing system</span></div><div class="line"><a name="l00183"></a><span class="lineno"> 183</span>&#160;<span class="comment"></span> } QUICKCPPLIB_BITFIELD_END(flag);</div></div><!-- fragment -->
+</div>
+</div>
<a id="a101620e9fff0c0e8c346af0e9de58b6a"></a>
<h2 class="memtitle"><span class="permalink"><a href="#a101620e9fff0c0e8c346af0e9de58b6a">&#9670;&nbsp;</a></span>set_append_only()</h2>