|
|
|
Functions | |
| virtual boost::afio::path | boost::afio::handle::path (bool refresh=false)=0 |
| Returns the path of this i/o handle right now if the handle is open and refresh is true, else last known good. May be null if the file has been deleted. | |
| virtual directory_entry | boost::afio::handle::direntry (metadata_flags wanted=directory_entry::metadata_fastpath())=0 |
| Returns a mostly filled directory_entry for the file or directory referenced by this handle. Use `metadata_flags::All` if you want it as complete as your platform allows, even at the cost of severe performance loss. | |
| virtual boost::afio::path | boost::afio::handle::target ()=0 |
| Returns the target path of this handle if it is a symbolic link. | |
| virtual void | boost::afio::handle::link (const path_req &req)=0 |
| Hard links the file to a new location on the same volume. | |
| virtual void | boost::afio::handle::unlink ()=0 |
| Unlinks the file from its present location as determined by path(true), which could be any hard link on those operating systems with an unstable path(true). Other links may remain to the same file. | |
| virtual void | boost::afio::handle::atomic_relink (const path_req &req)=0 |
| Links the file to a new location and unlinks the file from its present location as determined by path(true), atomically overwriting any file entry at the new location. Very useful for preparing file content elsewhere and once ready, atomically making it visible at some named location to other processes. Note that operating systems with an unstable path(true) may relink any hard link to the file to the new location. | |
| virtual boost::afio::path boost::afio::handle::path | ( | bool | refresh = false | ) | [pure virtual] |
Returns the path of this i/o handle right now if the handle is open and refresh is true, else last known good. May be null if the file has been deleted.
Note the refreshed path completely dereferences any intermediate symbolic links to return a truly absolute canonical path, and therefore may look quite different to before. Some operating systems unfortunately also return any one of the hard links to the file, so if hard links is greater than one the path refreshed will randomly permute.
Be aware that on Windows AFIO operates exclusively in the NT kernel namespace, NOT the Win32 namespace, and therefore paths you supply are converted by `afio::path` in NT kernel namespace paths. `normalise_path()` can convert an afio path back to a Filesystem TS path for you, but note that this may not be the path that was supplied originally. NT kernel namespace paths have a 32,767 character limit and an almost POSIX like lack of restrictions on naming or historical behaviour quirks, but as a result AFIO does not support DOS short names or any of the other historical Win32 filing system baggage.
| refresh | Whether to ask the OS for the current path of this handle. |
{ [raceguarantee FreeBSD..Paths are only refreshed for directories, not files.] [raceguarantee Linux, Windows..Paths are always refreshed and ignore other hard links.] [raceguarantee OS X..Paths are only refreshed for directories and files with a single hard link.] }
| virtual directory_entry boost::afio::handle::direntry | ( | metadata_flags | wanted = directory_entry::metadata_fastpath() | ) | [pure virtual] |
Returns a mostly filled directory_entry for the file or directory referenced by this handle. Use `metadata_flags::All` if you want it as complete as your platform allows, even at the cost of severe performance loss.
Related types: `__afio_directory_entry__`, `__afio_stat_t__`
| wanted | The metadata wanted. |
{ [raceguarantee FreeBSD..Race free if handle open for directories and regular files only, else if handle closed or a symlink race free up to the containing directory. All metadata is fetched in a single shot.] [raceguarantee Linux..Race free if handle open, else if handle closed race free up to the containing directory. All metadata is fetched in a single shot.] [raceguarantee OS X..Race free if handle open for directories and regular files only. No guarantees if handle closed or a symlink.] [raceguarantee Windows..Handle must be open and is always race free. Metadata may be fetched in a single shot if at least two categories requested, or else the following categories apply: (i) ino (ii) type, atim, mtim, ctim, birthtim, sparse, compressed (iii) nlink, size, allocated, blocks.] }
| virtual boost::afio::path boost::afio::handle::target | ( | ) | [pure virtual] |
Returns the target path of this handle if it is a symbolic link.
Be aware that on Windows AFIO operates exclusively in the NT kernel namespace, NOT the Win32 namespace, and therefore paths you supply are converted by `afio::path` in NT kernel namespace paths. `normalise_path()` can convert an afio path back to a Filesystem TS path for you, but note that this may not be the path that was supplied originally. NT kernel namespace paths have a 32,767 character limit and an almost POSIX like lack of restrictions on naming or historical behaviour quirks, but as a result AFIO does not support DOS short names or any of the other historical Win32 filing system baggage.
{ [raceguarantee FreeBSD..Race free up to the containing directory.] [raceguarantee Linux, Windows..Race free if handle open, else up to the containing directory.] [raceguarantee OS X..No guarantees.] }
| virtual void boost::afio::handle::link | ( | const path_req & | req | ) | [pure virtual] |
Hard links the file to a new location on the same volume.
If you wish to make a temporary file whose contents are ready appear at a location and error out if a file entry is already there, use link() and if success, unlink() on the former location. If you wish to always overwrite the destination, use atomic_relink() instead.
On Windows, the destination directory cannot have any handle opened to it with delete/rename privileges (`file_flags::write`) anywhere in the system. This is an operating system limitation.
Be aware that on Windows AFIO operates exclusively in the NT kernel namespace, NOT the Win32 namespace, and therefore paths you supply are converted by `afio::path` in NT kernel namespace paths. `normalise_path()` can convert an afio path back to a Filesystem TS path for you, but note that this may not be the path that was supplied originally. NT kernel namespace paths have a 32,767 character limit and an almost POSIX like lack of restrictions on naming or historical behaviour quirks, but as a result AFIO does not support DOS short names or any of the other historical Win32 filing system baggage.
Related types: `__afio_path_req__`
| req | The absolute or relative (in which case precondition specifies a directory) path to create a hard link at. |
{ [raceguarantee FreeBSD..Race free up to the containing directory for both source and target.] [raceguarantee Linux, Windows..Race free for source if handle open, else up to the containing directory. Race free up to the target directory.] [raceguarantee OS X..No guarantees.] }
| virtual void boost::afio::handle::unlink | ( | ) | [pure virtual] |
Unlinks the file from its present location as determined by path(true), which could be any hard link on those operating systems with an unstable path(true). Other links may remain to the same file.
On Microsoft Windows, this routine unlinks items as follows:
1. It tries to atomically rename the item to the root of the mounted volume it lives in with a .afiodXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX where the X's are a 128 bit crypto random hexadecimal. If that fails, it tries the next directory up, and the next after that until success if any. This rename may fail for any reason, including if it is a directory with open file handles somewhere within. If it fails, the rename is skipped.
2. It marks the item with hidden and system attributes to hide it from normal directory enumeration.
3. It sets the delete on last handle close flag. At some stl_future point Windows will delete the item, until which it will hang around in a zombie state with an unknowable name and location unopenable by any new processes.
The reason for such complexity is that this algorithm, if it renames successfully, neatly works around a number of annoying features in Windows, specifically that when you delete a file you actually don't delete it till an unknown amount of time later. This breaks code which tries to delete a directory tree, and finds that the directories won't delete because they still contain files supposedly deleted but actually not quite yet. By renaming the items as far away as possible, this problem ought to go away - unless of course that the user does not have permissions to write into any directory other than the one being eventually deleted, in which case you will still see the strange access denied and directory not empty errors from before.
Be aware that on Windows AFIO operates exclusively in the NT kernel namespace, NOT the Win32 namespace, and therefore paths you supply are converted by `afio::path` in NT kernel namespace paths. `normalise_path()` can convert an afio path back to a Filesystem TS path for you, but note that this may not be the path that was supplied originally. NT kernel namespace paths have a 32,767 character limit and an almost POSIX like lack of restrictions on naming or historical behaviour quirks, but as a result AFIO does not support DOS short names or any of the other historical Win32 filing system baggage.
Related types: `__afio_path_req__`
{ [raceguarantee FreeBSD, Linux..Race free up to the containing directory.] [raceguarantee Windows..Race free if handle open, else up to the containing directory.] [raceguarantee OS X..No guarantees.] }
| virtual void boost::afio::handle::atomic_relink | ( | const path_req & | req | ) | [pure virtual] |
Links the file to a new location and unlinks the file from its present location as determined by path(true), atomically overwriting any file entry at the new location. Very useful for preparing file content elsewhere and once ready, atomically making it visible at some named location to other processes. Note that operating systems with an unstable path(true) may relink any hard link to the file to the new location.
Note that not all filing systems guarantee the atomicity of the relink itself (i.e. the file may appear at two locations in the filing system for a period of time), though all supported platforms do guarantee the atomicity of the replaced location i.e. the location you are relinking to will always refer to some valid file to all readers, and will never be deleted or missing. Some filing systems may also fail to do the unlink if power is lost close to the relinking operation.
On Windows, the destination directory cannot have any handle opened to it with delete/rename privileges (`file_flags::write`) anywhere in the system. This is an operating system limitation.
Be aware that on Windows AFIO operates exclusively in the NT kernel namespace, NOT the Win32 namespace, and therefore paths you supply are converted by `afio::path` in NT kernel namespace paths. `normalise_path()` can convert an afio path back to a Filesystem TS path for you, but note that this may not be the path that was supplied originally. NT kernel namespace paths have a 32,767 character limit and an almost POSIX like lack of restrictions on naming or historical behaviour quirks, but as a result AFIO does not support DOS short names or any of the other historical Win32 filing system baggage.
Related types: `__afio_path_req__`
| req | The absolute or relative (in which case precondition specifies a directory) path to relink to. |
{ [raceguarantee FreeBSD, Linux..Race free up to the containing directory for both source and target.] [raceguarantee OS X..No guarantees.] [raceguarantee Windows..Race free for source if handle open, else up to the containing directory. Race free up to the target directory.] }
|
January, 2014 |
Copyright © 2013-2014 Niall Douglas, Cork, Ireland Copyright © 2013 Paul Kirth, California |