Alien-uv
view release on metacpan or search on metacpan
libuv/docs/src/fs.rst view on Meta::CPAN
.. warning::
If the destination path is created, but an error occurs while copying
the data, then the destination path is removed. There is a brief window
of time between closing and removing the file where another process
could access the file.
.. versionadded:: 1.14.0
.. versionchanged:: 1.20.0 `UV_FS_COPYFILE_FICLONE` and
`UV_FS_COPYFILE_FICLONE_FORCE` are supported.
.. c:function:: int uv_fs_sendfile(uv_loop_t* loop, uv_fs_t* req, uv_file out_fd, uv_file in_fd, int64_t in_offset, size_t length, uv_fs_cb cb)
Limited equivalent to :man:`sendfile(2)`.
.. c:function:: int uv_fs_access(uv_loop_t* loop, uv_fs_t* req, const char* path, int mode, uv_fs_cb cb)
Equivalent to :man:`access(2)` on Unix. Windows uses ``GetFileAttributesW()``.
.. c:function:: int uv_fs_chmod(uv_loop_t* loop, uv_fs_t* req, const char* path, int mode, uv_fs_cb cb)
.. c:function:: int uv_fs_fchmod(uv_loop_t* loop, uv_fs_t* req, uv_file file, int mode, uv_fs_cb cb)
Equivalent to :man:`chmod(2)` and :man:`fchmod(2)` respectively.
.. c:function:: int uv_fs_utime(uv_loop_t* loop, uv_fs_t* req, const char* path, double atime, double mtime, uv_fs_cb cb)
.. c:function:: int uv_fs_futime(uv_loop_t* loop, uv_fs_t* req, uv_file file, double atime, double mtime, uv_fs_cb cb)
Equivalent to :man:`utime(2)` and :man:`futime(2)` respectively.
.. note::
AIX: This function only works for AIX 7.1 and newer. It can still be called on older
versions but will return ``UV_ENOSYS``.
.. versionchanged:: 1.10.0 sub-second precission is supported on Windows
.. c:function:: int uv_fs_link(uv_loop_t* loop, uv_fs_t* req, const char* path, const char* new_path, uv_fs_cb cb)
Equivalent to :man:`link(2)`.
.. c:function:: int uv_fs_symlink(uv_loop_t* loop, uv_fs_t* req, const char* path, const char* new_path, int flags, uv_fs_cb cb)
Equivalent to :man:`symlink(2)`.
.. note::
On Windows the `flags` parameter can be specified to control how the symlink will
be created:
* ``UV_FS_SYMLINK_DIR``: indicates that `path` points to a directory.
* ``UV_FS_SYMLINK_JUNCTION``: request that the symlink is created
using junction points.
.. c:function:: int uv_fs_readlink(uv_loop_t* loop, uv_fs_t* req, const char* path, uv_fs_cb cb)
Equivalent to :man:`readlink(2)`.
The resulting string is stored in `req->ptr`.
.. c:function:: int uv_fs_realpath(uv_loop_t* loop, uv_fs_t* req, const char* path, uv_fs_cb cb)
Equivalent to :man:`realpath(3)` on Unix. Windows uses `GetFinalPathNameByHandle <https://msdn.microsoft.com/en-us/library/windows/desktop/aa364962(v=vs.85).aspx>`_.
The resulting string is stored in `req->ptr`.
.. warning::
This function has certain platform-specific caveats that were discovered when used in Node.
* macOS and other BSDs: this function will fail with UV_ELOOP if more than 32 symlinks are
found while resolving the given path. This limit is hardcoded and cannot be sidestepped.
* Windows: while this function works in the common case, there are a number of corner cases
where it doesn't:
- Paths in ramdisk volumes created by tools which sidestep the Volume Manager (such as ImDisk)
cannot be resolved.
- Inconsistent casing when using drive letters.
- Resolved path bypasses subst'd drives.
While this function can still be used, it's not recommended if scenarios such as the
above need to be supported.
The background story and some more details on these issues can be checked
`here <https://github.com/nodejs/node/issues/7726>`_.
.. note::
This function is not implemented on Windows XP and Windows Server 2003.
On these systems, UV_ENOSYS is returned.
.. versionadded:: 1.8.0
.. c:function:: int uv_fs_chown(uv_loop_t* loop, uv_fs_t* req, const char* path, uv_uid_t uid, uv_gid_t gid, uv_fs_cb cb)
.. c:function:: int uv_fs_fchown(uv_loop_t* loop, uv_fs_t* req, uv_file file, uv_uid_t uid, uv_gid_t gid, uv_fs_cb cb)
.. c:function:: int uv_fs_lchown(uv_loop_t* loop, uv_fs_t* req, const char* path, uv_uid_t uid, uv_gid_t gid, uv_fs_cb cb)
Equivalent to :man:`chown(2)`, :man:`fchown(2)` and :man:`lchown(2)` respectively.
.. note::
These functions are not implemented on Windows.
.. versionchanged:: 1.21.0 implemented uv_fs_lchown
.. c:function:: uv_fs_type uv_fs_get_type(const uv_fs_t* req)
Returns `req->fs_type`.
.. versionadded:: 1.19.0
.. c:function:: ssize_t uv_fs_get_result(const uv_fs_t* req)
Returns `req->result`.
.. versionadded:: 1.19.0
.. c:function:: void* uv_fs_get_ptr(const uv_fs_t* req)
Returns `req->ptr`.
.. versionadded:: 1.19.0
.. c:function:: const char* uv_fs_get_path(const uv_fs_t* req)
Returns `req->path`.
.. versionadded:: 1.19.0
.. c:function:: uv_stat_t* uv_fs_get_statbuf(uv_fs_t* req)
Returns `&req->statbuf`.
.. versionadded:: 1.19.0
.. seealso:: The :c:type:`uv_req_t` API functions also apply.
Helper functions
----------------
.. c:function:: uv_os_fd_t uv_get_osfhandle(int fd)
For a file descriptor in the C runtime, get the OS-dependent handle.
On UNIX, returns the ``fd`` intact. On Windows, this calls `_get_osfhandle <https://msdn.microsoft.com/en-us/library/ks2530z6.aspx>`_.
Note that the return value is still owned by the C runtime,
any attempts to close it or to use it after closing the fd may lead to malfunction.
.. versionadded:: 1.12.0
.. c:function:: int uv_open_osfhandle(uv_os_fd_t os_fd)
For a OS-dependent handle, get the file descriptor in the C runtime.
On UNIX, returns the ``os_fd`` intact. On Windows, this calls `_open_osfhandle <https://msdn.microsoft.com/en-us/library/bdts1c9x.aspx>`_.
Note that the return value is still owned by the CRT,
any attempts to close it or to use it after closing the handle may lead to malfunction.
.. versionadded:: 1.23.0
File open constants
-------------------
.. c:macro:: UV_FS_O_APPEND
The file is opened in append mode. Before each write, the file offset is
positioned at the end of the file.
.. c:macro:: UV_FS_O_CREAT
The file is created if it does not already exist.
.. c:macro:: UV_FS_O_DIRECT
File I/O is done directly to and from user-space buffers, which must be
aligned. Buffer size and address should be a multiple of the physical sector
size of the block device.
.. note::
`UV_FS_O_DIRECT` is supported on Linux, and on Windows via
`FILE_FLAG_NO_BUFFERING <https://msdn.microsoft.com/en-us/library/windows/desktop/cc644950.aspx>`_.
`UV_FS_O_DIRECT` is not supported on macOS.
.. c:macro:: UV_FS_O_DIRECTORY
If the path is not a directory, fail the open.
.. note::
`UV_FS_O_DIRECTORY` is not supported on Windows.
.. c:macro:: UV_FS_O_DSYNC
The file is opened for synchronous I/O. Write operations will complete once
all data and a minimum of metadata are flushed to disk.
.. note::
`UV_FS_O_DSYNC` is supported on Windows via
`FILE_FLAG_WRITE_THROUGH <https://msdn.microsoft.com/en-us/library/windows/desktop/cc644950.aspx>`_.
.. c:macro:: UV_FS_O_EXCL
If the `O_CREAT` flag is set and the file already exists, fail the open.
.. note::
In general, the behavior of `O_EXCL` is undefined if it is used without
`O_CREAT`. There is one exception: on Linux 2.6 and later, `O_EXCL` can
be used without `O_CREAT` if pathname refers to a block device. If the
block device is in use by the system (e.g., mounted), the open will fail
with the error `EBUSY`.
.. c:macro:: UV_FS_O_EXLOCK
Atomically obtain an exclusive lock.
.. note::
`UV_FS_O_EXLOCK` is only supported on macOS and Windows.
.. versionchanged:: 1.17.0 support is added for Windows.
.. c:macro:: UV_FS_O_NOATIME
Do not update the file access time when the file is read.
.. note::
`UV_FS_O_NOATIME` is not supported on Windows.
.. c:macro:: UV_FS_O_NOCTTY
If the path identifies a terminal device, opening the path will not cause
that terminal to become the controlling terminal for the process (if the
process does not already have one).
.. note::
`UV_FS_O_NOCTTY` is not supported on Windows.
.. c:macro:: UV_FS_O_NOFOLLOW
If the path is a symbolic link, fail the open.
.. note::
`UV_FS_O_NOFOLLOW` is not supported on Windows.
.. c:macro:: UV_FS_O_NONBLOCK
Open the file in nonblocking mode if possible.
.. note::
`UV_FS_O_NONBLOCK` is not supported on Windows.
.. c:macro:: UV_FS_O_RANDOM
Access is intended to be random. The system can use this as a hint to
optimize file caching.
.. note::
`UV_FS_O_RANDOM` is only supported on Windows via
`FILE_FLAG_RANDOM_ACCESS <https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858.aspx>`_.
.. c:macro:: UV_FS_O_RDONLY
Open the file for read-only access.
.. c:macro:: UV_FS_O_RDWR
Open the file for read-write access.
.. c:macro:: UV_FS_O_SEQUENTIAL
Access is intended to be sequential from beginning to end. The system can
use this as a hint to optimize file caching.
.. note::
`UV_FS_O_SEQUENTIAL` is only supported on Windows via
`FILE_FLAG_SEQUENTIAL_SCAN <https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858.aspx>`_.
.. c:macro:: UV_FS_O_SHORT_LIVED
The file is temporary and should not be flushed to disk if possible.
.. note::
`UV_FS_O_SHORT_LIVED` is only supported on Windows via
`FILE_ATTRIBUTE_TEMPORARY <https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858.aspx>`_.
.. c:macro:: UV_FS_O_SYMLINK
Open the symbolic link itself rather than the resource it points to.
.. c:macro:: UV_FS_O_SYNC
The file is opened for synchronous I/O. Write operations will complete once
all data and all metadata are flushed to disk.
.. note::
`UV_FS_O_SYNC` is supported on Windows via
`FILE_FLAG_WRITE_THROUGH <https://msdn.microsoft.com/en-us/library/windows/desktop/cc644950.aspx>`_.
.. c:macro:: UV_FS_O_TEMPORARY
The file is temporary and should not be flushed to disk if possible.
.. note::
`UV_FS_O_TEMPORARY` is only supported on Windows via
`FILE_ATTRIBUTE_TEMPORARY <https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858.aspx>`_.
.. c:macro:: UV_FS_O_TRUNC
If the file exists and is a regular file, and the file is opened
successfully for write access, its length shall be truncated to zero.
.. c:macro:: UV_FS_O_WRONLY
Open the file for write-only access.
( run in 0.716 second using v1.01-cache-2.11-cpan-e1769b4cff6 )