diff options
Diffstat (limited to 'classllfio__v2__xxx_1_1mapped__file__handle.html')
| -rw-r--r-- | classllfio__v2__xxx_1_1mapped__file__handle.html | 12 |
1 files changed, 6 insertions, 6 deletions
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> |