uvcc
libuv C++ bindings
uv::fs Class Reference

The base calss for filesystem requests. More...

#include "request-fs.hpp"

Inheritance diagram for uv::fs:
uv::request uv::fs::access uv::fs::chmod uv::fs::chown uv::fs::close uv::fs::link uv::fs::mkdir uv::fs::mkdtemp uv::fs::read uv::fs::readlink uv::fs::realpath uv::fs::rename uv::fs::rmdir uv::fs::scandir uv::fs::sendfile uv::fs::stat uv::fs::sync uv::fs::truncate uv::fs::unlink uv::fs::utime uv::fs::write

Classes

class  access
 Check user's permissions for a file. More...
 
class  chmod
 Change a file mode bits. More...
 
class  chown
 Change ownership of a file. (Not implemented on Windows.) More...
 
class  close
 Close a file handle. More...
 
class  link
 Create a new link to a file. More...
 
class  mkdir
 Create a directory. More...
 
class  mkdtemp
 Create a uniquely named temporary directory. More...
 
class  read
 Read data from a file. More...
 
class  readlink
 Read value of a symbolic link. More...
 
class  realpath
 Get canonicalized absolute pathname. More...
 
class  rename
 Change the name or location of a file. More...
 
class  rmdir
 Delete a directory. More...
 
class  scandir
 Scan a directory. More...
 
class  sendfile
 Transfer data between file descriptors. More...
 
class  stat
 Get information about a file. More...
 
class  sync
 Synchronize a file's state with storage device. More...
 
class  truncate
 Truncate a file to a specified length. More...
 
class  unlink
 Delete a file name and possibly the file itself that the name refers to. More...
 
class  utime
 Change file timestamps. More...
 
class  write
 Write data to a file. More...
 

Public Types

using uv_t = ::uv_fs_t
 
- Public Types inherited from uv::request
using uv_t = ::uv_req_t
 
using on_destroy_t = std::function< void(void *_data) >
 The function type of the callback called when the request object is about to be destroyed.
 

Public Member Functions

 fs (const fs &)=default
 
fsoperator= (const fs &)=default
 
 fs (fs &&) noexcept=default
 
fsoperator= (fs &&) noexcept=default
 
::uv_fs_type fs_type () const noexcept
 The tag indicating a subtype of the filesystem request. More...
 
uv::loop loop () const noexcept
 The libuv loop that started this filesystem request and where completion will be reported.
 
 operator const uv_t * () const noexcept
 
 operator uv_t * () noexcept
 
- Public Member Functions inherited from uv::request
 request (const request &_that)
 
requestoperator= (const request &_that)
 
 request (request &&_that) noexcept
 
requestoperator= (request &&_that) noexcept
 
void swap (request &_that) noexcept
 
std::uintptr_t id () const noexcept
 
long nrefs () const noexcept
 The current number of existing references to the same object as this request variable refers to.
 
int uv_status () const noexcept
 The status value returned by the last executed libuv API function on this request.
 
on_destroy_ton_destroy () const noexcept
 
::uv_req_type type () const noexcept
 The tag indicating a libuv type of the request. More...
 
const char * type_name () const noexcept
 A string containing the name of the request type.
 
void *const & data () const noexcept
 The pointer to the user-defined arbitrary data. libuv and uvcc does not use this field.
 
void *& data () noexcept
 
int cancel () noexcept
 Cancel a pending request. More...
 
 operator const uv_t * () const noexcept
 
 operator uv_t * () noexcept
 
 operator bool () const noexcept
 Equivalent to (uv_status() >= 0).
 

Detailed Description

The base calss for filesystem requests.

See also
libuv API documentation: Filesystem operations.
Warning
As far as all asynchronous file operations in libuv are run on the threadpool, i.e. in separate threads, pay attention when running asynchronous requests for sequential reading/writing from/to a file with the _offset value specified as of < 0 which means using of the "current file position". When the next read/write request on a file is scheduled after the previous one has completed and its callback has been called, everything will be OK. If several asynchronous requests intended for performing sequential input/output are scheduled as unchained operations, some or all of them can be actually preformed simultaneously in parallel threads and the result will most probably turn out to be not what was expected. Don't use the "current file position" dummy value in such a case, always designate a real effective file offset for each request run.

Definition at line 40 of file request-fs.hpp.

Member Function Documentation

◆ fs_type()

::uv_fs_type uv::fs::fs_type ( ) const
inlinenoexcept

The tag indicating a subtype of the filesystem request.

See also
libuv API documentation: uv_fs_type.

Definition at line 116 of file request-fs.hpp.


The documentation for this class was generated from the following file: