UVFile wrap a uv_file_t and a referencing counter

Note this is a differet data type from Std.IO.FileSystem 's one, the Input and Output instance use thread pool version functions.

libuv implements read and write method with both implict and explict offset capability. (negative offset result in read/write system call otherwise pread/pwrite), we provide implict offset interface with UVFile, which is NOT thread safe.

An offset bundled UVFileReader, UVFileWriter is also provided, which can be used concurrently. The offset is protected with MVar and increasing automatically.

Create a reader from an UVFile.

Note this will not increase UVFile's referencing counter.

Change reader's offset.

Create a writer from an UVFile.

Note this will not increase UVFile's referencing counter.

Change writer's offset.

init a file Resource, which open a file when used.

Resource closing will wait for the referencing counter goes down to zero (no reading or writing is in process), which can be a problem if you are using multiple readers or writers in multiple threads. In that case you have to stop all reading or writing thread if you don't want to block the resource thread.

Equivalent to mkdir(2).

Note mode is currently not implemented on Windows.

Equivalent to unlink(2).

Equivalent to http://linux.die.net/man/3/mkdtemp

Creates a temporary directory in the most secure manner possible. There are no race conditions in the directory’s creation. The directory is readable, writable, and searchable only by the creating user ID. The user of mkdtemp() is responsible for deleting the temporary directory and its contents when done with it.

Note: the argument is the prefix of the temporary directory, so no need to add XXXXXX ending.

Equivalent to rmdir(2).

Equivalent to scandir(3).

Note Unlike scandir(3), this function does not return the “.” and “..” entries.

Note On Linux, getting the type of an entry is only supported by some file systems (btrfs, ext2, ext3 and ext4 at the time of this writing), check the getdents(2) man page.

Equivalent to stat(2)

Equivalent to lstat(2)

Equivalent to fstat(2)

Equivalent to rename(2).

Note On Windows if this function fails with UV_EBUSY, UV_EPERM or UV_EACCES, it will retry to rename the file up to four times with 250ms wait between attempts before giving up. If both path and new_path are existing directories this function will work only if target directory is empty.

Equivalent to fsync(2).

Equivalent to fdatasync(2).

Equivalent to ftruncate(2).

Flags control copying.

• COPYFILE_EXCL: If present, uv_fs_copyfile() will fail with UV_EEXIST if the destination path already exists. The default behavior is to overwrite the destination if it exists.
• COPYFILE_FICLONE: If present, uv_fs_copyfile() will attempt to create a copy-on-write reflink. If the underlying platform does not support copy-on-write, then a fallback copy mechanism is used.

Copies a file from path to new_path.

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.

Equivalent to access(2) on Unix. Windows uses GetFileAttributesW().

Equivalent to chmod(2).

Equivalent to fchmod(2).

Equivalent to utime(2).

libuv choose Double type due to cross platform concerns, we only provide micro-second precision:

• second = v
• nanosecond = (v * 1000000) % 1000000 * 1000;

second and nanosecond are fields in UVTimeSpec respectively.

Note libuv prior to v1.23.1 have issues which may result in nanosecond not set, futime doesn't have

Equivalent to futime(2).

Same precision notes with utime.

Equivalent to link(2).

Equivalent to symlink(2).

| Note On Windows the flags parameter can be specified to control how the symlink will be created.

• SYMLINK_DIR: indicates that path points to a directory.
• SYMLINK_JUNCTION: request that the symlink is created using junction points.

On other platforms these flags are ignored.

Equivalent to readlink(2).

Equivalent to realpath(3) on Unix. Windows uses GetFinalPathNameByHandle.

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.

Note This function is not implemented on Windows XP and Windows Server 2003. On these systems, UV_ENOSYS is returned.