diff options
Diffstat (limited to 'classllfio__v2__xxx_1_1section__handle.html')
| -rw-r--r-- | classllfio__v2__xxx_1_1section__handle.html | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/classllfio__v2__xxx_1_1section__handle.html b/classllfio__v2__xxx_1_1section__handle.html index 0da5be71..136289e4 100644 --- a/classllfio__v2__xxx_1_1section__handle.html +++ b/classllfio__v2__xxx_1_1section__handle.html @@ -573,8 +573,8 @@ flag </td><td class="memItemRight" valign="bottom"><b>_flags</b> {flag::non </table> </div><div class="memdoc"> <p>Returns the current path of the open handle as said by the operating system. Note that you are NOT guaranteed that any path refreshed bears any resemblance to the original, some operating systems will return some different path which still reaches the same inode via some other route e.g. hardlinks, dereferenced symbolic links, etc. Windows and Linux correctly track changes to the specific path the handle was opened with, not getting confused by other hard links. MacOS nearly gets it right, but under some circumstances e.g. renaming may switch to a different hard link's path which is almost certainly a bug.</p> -<p>If AFIO was not able to determine the current path for this open handle e.g. the inode has been unlinked, it returns an empty path. Be aware that FreeBSD can return an empty (deleted) path for file inodes no longer cached by the kernel path cache, AFIO cannot detect the difference. FreeBSD will also return any path leading to the inode if it is hard linked. FreeBSD does implement path retrieval for directory inodes correctly however, and see <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> -<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in AFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call AFIO appropriately.</p> +<p>If LLFIO was not able to determine the current path for this open handle e.g. the inode has been unlinked, it returns an empty path. Be aware that FreeBSD can return an empty (deleted) path for file inodes no longer cached by the kernel path cache, LLFIO cannot detect the difference. FreeBSD will also return any path leading to the inode if it is hard linked. FreeBSD does implement path retrieval for directory inodes correctly however, and see <code>algorithm::stablized_path<T></code> for a handle adapter which makes use of that.</p> +<p>On Linux if <code>/proc</code> is not mounted, this call fails with an error. All APIs in LLFIO which require the use of <code>current_path()</code> can be told to not use it e.g. <code>flag::disable_safety_unlinks</code>. It is up to you to detect if <code>current_path()</code> is not working, and to change how you call LLFIO appropriately.</p> <dl class="section warning"><dt>Warning</dt><dd>This call is expensive, it always asks the kernel for the current path, and no checking is done to ensure what the kernel returns is accurate or even sensible. Be aware that despite these precautions, paths are unstable and <b>can change randomly at any moment</b>. Most code written to use absolute file systems paths is <b>racy</b>, so don't do it, use <code>path_handle</code> to fix a base location on the file system and work from that anchor instead!</dd></dl> <dl class="section user"><dt>Memory Allocations</dt><dd>At least one malloc for the <code>path_type</code>, likely several more. </dd></dl> <dl class="section see"><dt>See also</dt><dd><code>algorithm::cached_parent_handle_adapter<T></code> which overrides this with an implementation based on retrieving the current path of a cached handle to the parent directory. On platforms with instability or failure to retrieve the correct current path for regular files, the cached parent handle adapter works around the problem by taking advantage of directory inodes not having the same instability problems on any platform. </dd></dl> |