rust/src/libstd/sys/unix/fs.rs

1086 lines
35 KiB
Rust
Raw Normal View History

2019-02-10 19:23:21 +00:00
use crate::os::unix::prelude::*;
use crate::ffi::{CString, CStr, OsString, OsStr};
use crate::fmt;
use crate::io::{self, Error, ErrorKind, SeekFrom, IoSlice, IoSliceMut};
2019-02-10 19:23:21 +00:00
use crate::mem;
use crate::path::{Path, PathBuf};
use crate::ptr;
use crate::sync::Arc;
use crate::sys::fd::FileDesc;
use crate::sys::time::SystemTime;
use crate::sys::{cvt, cvt_r};
use crate::sys_common::{AsInner, FromInner};
use libc::{c_int, mode_t};
#[cfg(any(target_os = "linux", target_os = "emscripten", target_os = "l4re"))]
2016-02-15 00:27:18 +00:00
use libc::{stat64, fstat64, lstat64, off64_t, ftruncate64, lseek64, dirent64, readdir64_r, open64};
2018-06-25 18:42:27 +00:00
#[cfg(any(target_os = "linux", target_os = "emscripten"))]
use libc::fstatat64;
#[cfg(any(target_os = "linux", target_os = "emscripten", target_os = "android"))]
2018-06-25 18:42:27 +00:00
use libc::dirfd;
#[cfg(target_os = "android")]
2018-06-25 18:42:27 +00:00
use libc::{stat as stat64, fstat as fstat64, fstatat as fstatat64, lstat as lstat64, lseek64,
dirent as dirent64, open as open64};
#[cfg(not(any(target_os = "linux",
target_os = "emscripten",
target_os = "l4re",
target_os = "android")))]
2016-02-15 00:09:57 +00:00
use libc::{stat as stat64, fstat as fstat64, lstat as lstat64, off_t as off64_t,
2016-02-15 00:27:18 +00:00
ftruncate as ftruncate64, lseek as lseek64, dirent as dirent64, open as open64};
#[cfg(not(any(target_os = "linux",
target_os = "emscripten",
target_os = "solaris",
target_os = "l4re",
target_os = "fuchsia")))]
2016-02-15 00:24:02 +00:00
use libc::{readdir_r as readdir64_r};
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
wasi: Fill out `std::fs` module for WASI This commit fills out the `std::fs` module and implementation for WASI. Not all APIs are implemented, such as permissions-related ones and `canonicalize`, but all others APIs have been implemented and very lightly tested so far. We'll eventually want to run a more exhaustive test suite! For now the highlights of this commit are: * The `std::fs::File` type is now backed by `WasiFd`, a raw WASI file descriptor. * All APIs in `std::fs` (except permissions/canonicalize) have implementations for the WASI target. * A suite of unstable extension traits were added to `std::os::wasi::fs`. These traits expose the raw filesystem functionality of WASI, namely `*at` syscalls (opening a file relative to an already opened one, for example). Additionally metadata only available on wasi is exposed through these traits. Perhaps one of the most notable parts is the implementation of path-taking APIs. WASI actually has no fundamental API that just takes a path, but rather everything is relative to a previously opened file descriptor. To allow existing APIs to work (that only take a path) WASI has a few syscalls to learn about "pre opened" file descriptors by the runtime. We use these to build a map of existing directory names to file descriptors, and then when using a path we try to anchor it at an already-opened file. This support is very rudimentary though and is intended to be shared with C since it's likely to be so tricky. For now though the C library doesn't expose quite an API for us to use, so we implement it for now and will swap it out as soon as one is available.
2019-03-29 22:57:14 +00:00
pub use crate::sys_common::fs::remove_dir_all;
pub struct File(FileDesc);
#[derive(Clone)]
pub struct FileAttr {
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
stat: stat64,
}
// all DirEntry's will have a reference to this struct
struct InnerReadDir {
dirp: Dir,
root: PathBuf,
}
#[derive(Clone)]
pub struct ReadDir {
inner: Arc<InnerReadDir>,
end_of_stream: bool,
}
struct Dir(*mut libc::DIR);
unsafe impl Send for Dir {}
unsafe impl Sync for Dir {}
pub struct DirEntry {
2016-02-15 00:24:02 +00:00
entry: dirent64,
dir: ReadDir,
// We need to store an owned copy of the entry name
// on Solaris and Fuchsia because a) it uses a zero-length
// array to store the name, b) its lifetime between readdir
// calls is not guaranteed.
#[cfg(any(target_os = "solaris", target_os = "fuchsia"))]
name: Box<[u8]>
}
#[derive(Clone, Debug)]
pub struct OpenOptions {
// generic
read: bool,
write: bool,
append: bool,
truncate: bool,
create: bool,
create_new: bool,
// system-specific
custom_flags: i32,
mode: mode_t,
}
#[derive(Clone, PartialEq, Eq, Debug)]
pub struct FilePermissions { mode: mode_t }
#[derive(Copy, Clone, PartialEq, Eq, Hash, Debug)]
std: Expand the area of std::fs This commit is an implementation of [RFC 1044][rfc] which adds additional surface area to the `std::fs` module. All new APIs are `#[unstable]` behind assorted feature names for each one. [rfc]: https://github.com/rust-lang/rfcs/pull/1044 The new APIs added are: * `fs::canonicalize` - bindings to `realpath` on unix and `GetFinalPathNameByHandle` on windows. * `fs::symlink_metadata` - similar to `lstat` on unix * `fs::FileType` and accessor methods as `is_{file,dir,symlink}` * `fs::Metadata::file_type` - accessor for the raw file type * `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows but requires a syscall on unix. * `fs::DirEntry::file_type` - access the file type which may not require a syscall on most platforms. * `fs::DirEntry::file_name` - access just the file name without leading components. * `fs::PathExt::symlink_metadata` - convenience method for the top-level function. * `fs::PathExt::canonicalize` - convenience method for the top-level function. * `fs::PathExt::read_link` - convenience method for the top-level function. * `fs::PathExt::read_dir` - convenience method for the top-level function. * `std::os::raw` - type definitions for raw OS/C types available on all platforms. * `std::os::$platform` - new modules have been added for all currently supported platforms (e.g. those more specific than just `unix`). * `std::os::$platform::raw` - platform-specific type definitions. These modules are populated with the bare essentials necessary for lowing I/O types into their raw representations, and currently largely consist of the `stat` definition for unix platforms. This commit also deprecates `Metadata::{modified, accessed}` in favor of inspecting the raw representations via the lowering methods of `Metadata`.
2015-04-16 06:21:13 +00:00
pub struct FileType { mode: mode_t }
#[derive(Debug)]
pub struct DirBuilder { mode: mode_t }
impl FileAttr {
pub fn size(&self) -> u64 { self.stat.st_size as u64 }
pub fn perm(&self) -> FilePermissions {
2017-09-17 21:42:58 +00:00
FilePermissions { mode: (self.stat.st_mode as mode_t) }
}
std: Expand the area of std::fs This commit is an implementation of [RFC 1044][rfc] which adds additional surface area to the `std::fs` module. All new APIs are `#[unstable]` behind assorted feature names for each one. [rfc]: https://github.com/rust-lang/rfcs/pull/1044 The new APIs added are: * `fs::canonicalize` - bindings to `realpath` on unix and `GetFinalPathNameByHandle` on windows. * `fs::symlink_metadata` - similar to `lstat` on unix * `fs::FileType` and accessor methods as `is_{file,dir,symlink}` * `fs::Metadata::file_type` - accessor for the raw file type * `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows but requires a syscall on unix. * `fs::DirEntry::file_type` - access the file type which may not require a syscall on most platforms. * `fs::DirEntry::file_name` - access just the file name without leading components. * `fs::PathExt::symlink_metadata` - convenience method for the top-level function. * `fs::PathExt::canonicalize` - convenience method for the top-level function. * `fs::PathExt::read_link` - convenience method for the top-level function. * `fs::PathExt::read_dir` - convenience method for the top-level function. * `std::os::raw` - type definitions for raw OS/C types available on all platforms. * `std::os::$platform` - new modules have been added for all currently supported platforms (e.g. those more specific than just `unix`). * `std::os::$platform::raw` - platform-specific type definitions. These modules are populated with the bare essentials necessary for lowing I/O types into their raw representations, and currently largely consist of the `stat` definition for unix platforms. This commit also deprecates `Metadata::{modified, accessed}` in favor of inspecting the raw representations via the lowering methods of `Metadata`.
2015-04-16 06:21:13 +00:00
pub fn file_type(&self) -> FileType {
FileType { mode: self.stat.st_mode as mode_t }
}
}
#[cfg(target_os = "netbsd")]
impl FileAttr {
pub fn modified(&self) -> io::Result<SystemTime> {
Ok(SystemTime::from(libc::timespec {
tv_sec: self.stat.st_mtime as libc::time_t,
tv_nsec: self.stat.st_mtimensec as libc::c_long,
}))
}
pub fn accessed(&self) -> io::Result<SystemTime> {
Ok(SystemTime::from(libc::timespec {
tv_sec: self.stat.st_atime as libc::time_t,
tv_nsec: self.stat.st_atimensec as libc::c_long,
}))
}
pub fn created(&self) -> io::Result<SystemTime> {
Ok(SystemTime::from(libc::timespec {
tv_sec: self.stat.st_birthtime as libc::time_t,
tv_nsec: self.stat.st_birthtimensec as libc::c_long,
}))
}
}
std: Stabilize APIs for the 1.10 release This commit applies the FCP decisions made by the libs team for the 1.10 cycle, including both new stabilizations and deprecations. Specifically, the list of APIs is: Stabilized: * `os::windows::fs::OpenOptionsExt::access_mode` * `os::windows::fs::OpenOptionsExt::share_mode` * `os::windows::fs::OpenOptionsExt::custom_flags` * `os::windows::fs::OpenOptionsExt::attributes` * `os::windows::fs::OpenOptionsExt::security_qos_flags` * `os::unix::fs::OpenOptionsExt::custom_flags` * `sync::Weak::new` * `Default for sync::Weak` * `panic::set_hook` * `panic::take_hook` * `panic::PanicInfo` * `panic::PanicInfo::payload` * `panic::PanicInfo::location` * `panic::Location` * `panic::Location::file` * `panic::Location::line` * `ffi::CStr::from_bytes_with_nul` * `ffi::CStr::from_bytes_with_nul_unchecked` * `ffi::FromBytesWithNulError` * `fs::Metadata::modified` * `fs::Metadata::accessed` * `fs::Metadata::created` * `sync::atomic::Atomic{Usize,Isize,Bool,Ptr}::compare_exchange` * `sync::atomic::Atomic{Usize,Isize,Bool,Ptr}::compare_exchange_weak` * `collections::{btree,hash}_map::{Occupied,Vacant,}Entry::key` * `os::unix::net::{UnixStream, UnixListener, UnixDatagram, SocketAddr}` * `SocketAddr::is_unnamed` * `SocketAddr::as_pathname` * `UnixStream::connect` * `UnixStream::pair` * `UnixStream::try_clone` * `UnixStream::local_addr` * `UnixStream::peer_addr` * `UnixStream::set_read_timeout` * `UnixStream::set_write_timeout` * `UnixStream::read_timeout` * `UnixStream::write_Timeout` * `UnixStream::set_nonblocking` * `UnixStream::take_error` * `UnixStream::shutdown` * Read/Write/RawFd impls for `UnixStream` * `UnixListener::bind` * `UnixListener::accept` * `UnixListener::try_clone` * `UnixListener::local_addr` * `UnixListener::set_nonblocking` * `UnixListener::take_error` * `UnixListener::incoming` * RawFd impls for `UnixListener` * `UnixDatagram::bind` * `UnixDatagram::unbound` * `UnixDatagram::pair` * `UnixDatagram::connect` * `UnixDatagram::try_clone` * `UnixDatagram::local_addr` * `UnixDatagram::peer_addr` * `UnixDatagram::recv_from` * `UnixDatagram::recv` * `UnixDatagram::send_to` * `UnixDatagram::send` * `UnixDatagram::set_read_timeout` * `UnixDatagram::set_write_timeout` * `UnixDatagram::read_timeout` * `UnixDatagram::write_timeout` * `UnixDatagram::set_nonblocking` * `UnixDatagram::take_error` * `UnixDatagram::shutdown` * RawFd impls for `UnixDatagram` * `{BTree,Hash}Map::values_mut` * `<[_]>::binary_search_by_key` Deprecated: * `StaticCondvar` - this, and all other static synchronization primitives below, are usable today through the lazy-static crate on stable Rust today. Additionally, we'd like the non-static versions to be directly usable in a static context one day, so they're unlikely to be the final forms of the APIs in any case. * `CONDVAR_INIT` * `StaticMutex` * `MUTEX_INIT` * `StaticRwLock` * `RWLOCK_INIT` * `iter::Peekable::is_empty` Closes #27717 Closes #27720 cc #27784 (but encode methods still exist) Closes #30014 Closes #30425 Closes #30449 Closes #31190 Closes #31399 Closes #31767 Closes #32111 Closes #32281 Closes #32312 Closes #32551 Closes #33018
2016-05-17 18:57:07 +00:00
#[cfg(not(target_os = "netbsd"))]
impl FileAttr {
pub fn modified(&self) -> io::Result<SystemTime> {
Ok(SystemTime::from(libc::timespec {
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
tv_sec: self.stat.st_mtime as libc::time_t,
2017-10-19 17:49:59 +00:00
tv_nsec: self.stat.st_mtime_nsec as _,
}))
}
pub fn accessed(&self) -> io::Result<SystemTime> {
Ok(SystemTime::from(libc::timespec {
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
tv_sec: self.stat.st_atime as libc::time_t,
2017-10-19 17:49:59 +00:00
tv_nsec: self.stat.st_atime_nsec as _,
}))
}
2019-05-13 07:13:07 +00:00
#[cfg(any(target_os = "freebsd",
std: Stabilize APIs for the 1.10 release This commit applies the FCP decisions made by the libs team for the 1.10 cycle, including both new stabilizations and deprecations. Specifically, the list of APIs is: Stabilized: * `os::windows::fs::OpenOptionsExt::access_mode` * `os::windows::fs::OpenOptionsExt::share_mode` * `os::windows::fs::OpenOptionsExt::custom_flags` * `os::windows::fs::OpenOptionsExt::attributes` * `os::windows::fs::OpenOptionsExt::security_qos_flags` * `os::unix::fs::OpenOptionsExt::custom_flags` * `sync::Weak::new` * `Default for sync::Weak` * `panic::set_hook` * `panic::take_hook` * `panic::PanicInfo` * `panic::PanicInfo::payload` * `panic::PanicInfo::location` * `panic::Location` * `panic::Location::file` * `panic::Location::line` * `ffi::CStr::from_bytes_with_nul` * `ffi::CStr::from_bytes_with_nul_unchecked` * `ffi::FromBytesWithNulError` * `fs::Metadata::modified` * `fs::Metadata::accessed` * `fs::Metadata::created` * `sync::atomic::Atomic{Usize,Isize,Bool,Ptr}::compare_exchange` * `sync::atomic::Atomic{Usize,Isize,Bool,Ptr}::compare_exchange_weak` * `collections::{btree,hash}_map::{Occupied,Vacant,}Entry::key` * `os::unix::net::{UnixStream, UnixListener, UnixDatagram, SocketAddr}` * `SocketAddr::is_unnamed` * `SocketAddr::as_pathname` * `UnixStream::connect` * `UnixStream::pair` * `UnixStream::try_clone` * `UnixStream::local_addr` * `UnixStream::peer_addr` * `UnixStream::set_read_timeout` * `UnixStream::set_write_timeout` * `UnixStream::read_timeout` * `UnixStream::write_Timeout` * `UnixStream::set_nonblocking` * `UnixStream::take_error` * `UnixStream::shutdown` * Read/Write/RawFd impls for `UnixStream` * `UnixListener::bind` * `UnixListener::accept` * `UnixListener::try_clone` * `UnixListener::local_addr` * `UnixListener::set_nonblocking` * `UnixListener::take_error` * `UnixListener::incoming` * RawFd impls for `UnixListener` * `UnixDatagram::bind` * `UnixDatagram::unbound` * `UnixDatagram::pair` * `UnixDatagram::connect` * `UnixDatagram::try_clone` * `UnixDatagram::local_addr` * `UnixDatagram::peer_addr` * `UnixDatagram::recv_from` * `UnixDatagram::recv` * `UnixDatagram::send_to` * `UnixDatagram::send` * `UnixDatagram::set_read_timeout` * `UnixDatagram::set_write_timeout` * `UnixDatagram::read_timeout` * `UnixDatagram::write_timeout` * `UnixDatagram::set_nonblocking` * `UnixDatagram::take_error` * `UnixDatagram::shutdown` * RawFd impls for `UnixDatagram` * `{BTree,Hash}Map::values_mut` * `<[_]>::binary_search_by_key` Deprecated: * `StaticCondvar` - this, and all other static synchronization primitives below, are usable today through the lazy-static crate on stable Rust today. Additionally, we'd like the non-static versions to be directly usable in a static context one day, so they're unlikely to be the final forms of the APIs in any case. * `CONDVAR_INIT` * `StaticMutex` * `MUTEX_INIT` * `StaticRwLock` * `RWLOCK_INIT` * `iter::Peekable::is_empty` Closes #27717 Closes #27720 cc #27784 (but encode methods still exist) Closes #30014 Closes #30425 Closes #30449 Closes #31190 Closes #31399 Closes #31767 Closes #32111 Closes #32281 Closes #32312 Closes #32551 Closes #33018
2016-05-17 18:57:07 +00:00
target_os = "openbsd",
target_os = "macos",
target_os = "ios"))]
pub fn created(&self) -> io::Result<SystemTime> {
Ok(SystemTime::from(libc::timespec {
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
tv_sec: self.stat.st_birthtime as libc::time_t,
tv_nsec: self.stat.st_birthtime_nsec as libc::c_long,
}))
}
2019-05-13 07:13:07 +00:00
#[cfg(not(any(target_os = "freebsd",
std: Stabilize APIs for the 1.10 release This commit applies the FCP decisions made by the libs team for the 1.10 cycle, including both new stabilizations and deprecations. Specifically, the list of APIs is: Stabilized: * `os::windows::fs::OpenOptionsExt::access_mode` * `os::windows::fs::OpenOptionsExt::share_mode` * `os::windows::fs::OpenOptionsExt::custom_flags` * `os::windows::fs::OpenOptionsExt::attributes` * `os::windows::fs::OpenOptionsExt::security_qos_flags` * `os::unix::fs::OpenOptionsExt::custom_flags` * `sync::Weak::new` * `Default for sync::Weak` * `panic::set_hook` * `panic::take_hook` * `panic::PanicInfo` * `panic::PanicInfo::payload` * `panic::PanicInfo::location` * `panic::Location` * `panic::Location::file` * `panic::Location::line` * `ffi::CStr::from_bytes_with_nul` * `ffi::CStr::from_bytes_with_nul_unchecked` * `ffi::FromBytesWithNulError` * `fs::Metadata::modified` * `fs::Metadata::accessed` * `fs::Metadata::created` * `sync::atomic::Atomic{Usize,Isize,Bool,Ptr}::compare_exchange` * `sync::atomic::Atomic{Usize,Isize,Bool,Ptr}::compare_exchange_weak` * `collections::{btree,hash}_map::{Occupied,Vacant,}Entry::key` * `os::unix::net::{UnixStream, UnixListener, UnixDatagram, SocketAddr}` * `SocketAddr::is_unnamed` * `SocketAddr::as_pathname` * `UnixStream::connect` * `UnixStream::pair` * `UnixStream::try_clone` * `UnixStream::local_addr` * `UnixStream::peer_addr` * `UnixStream::set_read_timeout` * `UnixStream::set_write_timeout` * `UnixStream::read_timeout` * `UnixStream::write_Timeout` * `UnixStream::set_nonblocking` * `UnixStream::take_error` * `UnixStream::shutdown` * Read/Write/RawFd impls for `UnixStream` * `UnixListener::bind` * `UnixListener::accept` * `UnixListener::try_clone` * `UnixListener::local_addr` * `UnixListener::set_nonblocking` * `UnixListener::take_error` * `UnixListener::incoming` * RawFd impls for `UnixListener` * `UnixDatagram::bind` * `UnixDatagram::unbound` * `UnixDatagram::pair` * `UnixDatagram::connect` * `UnixDatagram::try_clone` * `UnixDatagram::local_addr` * `UnixDatagram::peer_addr` * `UnixDatagram::recv_from` * `UnixDatagram::recv` * `UnixDatagram::send_to` * `UnixDatagram::send` * `UnixDatagram::set_read_timeout` * `UnixDatagram::set_write_timeout` * `UnixDatagram::read_timeout` * `UnixDatagram::write_timeout` * `UnixDatagram::set_nonblocking` * `UnixDatagram::take_error` * `UnixDatagram::shutdown` * RawFd impls for `UnixDatagram` * `{BTree,Hash}Map::values_mut` * `<[_]>::binary_search_by_key` Deprecated: * `StaticCondvar` - this, and all other static synchronization primitives below, are usable today through the lazy-static crate on stable Rust today. Additionally, we'd like the non-static versions to be directly usable in a static context one day, so they're unlikely to be the final forms of the APIs in any case. * `CONDVAR_INIT` * `StaticMutex` * `MUTEX_INIT` * `StaticRwLock` * `RWLOCK_INIT` * `iter::Peekable::is_empty` Closes #27717 Closes #27720 cc #27784 (but encode methods still exist) Closes #30014 Closes #30425 Closes #30449 Closes #31190 Closes #31399 Closes #31767 Closes #32111 Closes #32281 Closes #32312 Closes #32551 Closes #33018
2016-05-17 18:57:07 +00:00
target_os = "openbsd",
target_os = "macos",
target_os = "ios")))]
pub fn created(&self) -> io::Result<SystemTime> {
Err(io::Error::new(io::ErrorKind::Other,
"creation time is not available on this platform \
currently"))
}
}
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
impl AsInner<stat64> for FileAttr {
fn as_inner(&self) -> &stat64 { &self.stat }
std: Expand the area of std::fs This commit is an implementation of [RFC 1044][rfc] which adds additional surface area to the `std::fs` module. All new APIs are `#[unstable]` behind assorted feature names for each one. [rfc]: https://github.com/rust-lang/rfcs/pull/1044 The new APIs added are: * `fs::canonicalize` - bindings to `realpath` on unix and `GetFinalPathNameByHandle` on windows. * `fs::symlink_metadata` - similar to `lstat` on unix * `fs::FileType` and accessor methods as `is_{file,dir,symlink}` * `fs::Metadata::file_type` - accessor for the raw file type * `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows but requires a syscall on unix. * `fs::DirEntry::file_type` - access the file type which may not require a syscall on most platforms. * `fs::DirEntry::file_name` - access just the file name without leading components. * `fs::PathExt::symlink_metadata` - convenience method for the top-level function. * `fs::PathExt::canonicalize` - convenience method for the top-level function. * `fs::PathExt::read_link` - convenience method for the top-level function. * `fs::PathExt::read_dir` - convenience method for the top-level function. * `std::os::raw` - type definitions for raw OS/C types available on all platforms. * `std::os::$platform` - new modules have been added for all currently supported platforms (e.g. those more specific than just `unix`). * `std::os::$platform::raw` - platform-specific type definitions. These modules are populated with the bare essentials necessary for lowing I/O types into their raw representations, and currently largely consist of the `stat` definition for unix platforms. This commit also deprecates `Metadata::{modified, accessed}` in favor of inspecting the raw representations via the lowering methods of `Metadata`.
2015-04-16 06:21:13 +00:00
}
impl FilePermissions {
pub fn readonly(&self) -> bool {
// check if any class (owner, group, others) has write permission
self.mode & 0o222 == 0
}
pub fn set_readonly(&mut self, readonly: bool) {
if readonly {
// remove write permission for all classes; equivalent to `chmod a-w <file>`
self.mode &= !0o222;
} else {
// add write permission for all classes; equivalent to `chmod a+w <file>`
self.mode |= 0o222;
}
}
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
pub fn mode(&self) -> u32 { self.mode as u32 }
std: Expand the area of std::fs This commit is an implementation of [RFC 1044][rfc] which adds additional surface area to the `std::fs` module. All new APIs are `#[unstable]` behind assorted feature names for each one. [rfc]: https://github.com/rust-lang/rfcs/pull/1044 The new APIs added are: * `fs::canonicalize` - bindings to `realpath` on unix and `GetFinalPathNameByHandle` on windows. * `fs::symlink_metadata` - similar to `lstat` on unix * `fs::FileType` and accessor methods as `is_{file,dir,symlink}` * `fs::Metadata::file_type` - accessor for the raw file type * `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows but requires a syscall on unix. * `fs::DirEntry::file_type` - access the file type which may not require a syscall on most platforms. * `fs::DirEntry::file_name` - access just the file name without leading components. * `fs::PathExt::symlink_metadata` - convenience method for the top-level function. * `fs::PathExt::canonicalize` - convenience method for the top-level function. * `fs::PathExt::read_link` - convenience method for the top-level function. * `fs::PathExt::read_dir` - convenience method for the top-level function. * `std::os::raw` - type definitions for raw OS/C types available on all platforms. * `std::os::$platform` - new modules have been added for all currently supported platforms (e.g. those more specific than just `unix`). * `std::os::$platform::raw` - platform-specific type definitions. These modules are populated with the bare essentials necessary for lowing I/O types into their raw representations, and currently largely consist of the `stat` definition for unix platforms. This commit also deprecates `Metadata::{modified, accessed}` in favor of inspecting the raw representations via the lowering methods of `Metadata`.
2015-04-16 06:21:13 +00:00
}
impl FileType {
pub fn is_dir(&self) -> bool { self.is(libc::S_IFDIR) }
pub fn is_file(&self) -> bool { self.is(libc::S_IFREG) }
pub fn is_symlink(&self) -> bool { self.is(libc::S_IFLNK) }
pub fn is(&self, mode: mode_t) -> bool { self.mode & libc::S_IFMT == mode }
}
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
impl FromInner<u32> for FilePermissions {
fn from_inner(mode: u32) -> FilePermissions {
FilePermissions { mode: mode as mode_t }
}
}
impl fmt::Debug for ReadDir {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
// This will only be called from std::fs::ReadDir, which will add a "ReadDir()" frame.
// Thus the result will be e g 'ReadDir("/home")'
fmt::Debug::fmt(&*self.inner.root, f)
}
}
impl Iterator for ReadDir {
type Item = io::Result<DirEntry>;
#[cfg(any(target_os = "solaris", target_os = "fuchsia"))]
2016-01-21 16:30:22 +00:00
fn next(&mut self) -> Option<io::Result<DirEntry>> {
2019-02-10 19:23:21 +00:00
use crate::slice;
2016-01-21 16:30:22 +00:00
unsafe {
loop {
// Although readdir_r(3) would be a correct function to use here because
// of the thread safety, on Illumos and Fuchsia the readdir(3C) function
// is safe to use in threaded applications and it is generally preferred
// over the readdir_r(3C) function.
super::os::set_errno(0);
let entry_ptr = libc::readdir(self.inner.dirp.0);
2016-01-21 16:30:22 +00:00
if entry_ptr.is_null() {
// NULL can mean either the end is reached or an error occurred.
// So we had to clear errno beforehand to check for an error now.
return match super::os::errno() {
0 => None,
e => Some(Err(Error::from_raw_os_error(e))),
}
2016-01-21 16:30:22 +00:00
}
let name = (*entry_ptr).d_name.as_ptr();
let namelen = libc::strlen(name) as usize;
let ret = DirEntry {
entry: *entry_ptr,
2019-02-10 19:23:21 +00:00
name: slice::from_raw_parts(name as *const u8,
namelen as usize).to_owned().into_boxed_slice(),
dir: self.clone()
2016-01-21 16:30:22 +00:00
};
if ret.name_bytes() != b"." && ret.name_bytes() != b".." {
return Some(Ok(ret))
}
}
}
}
#[cfg(not(any(target_os = "solaris", target_os = "fuchsia")))]
fn next(&mut self) -> Option<io::Result<DirEntry>> {
if self.end_of_stream {
return None;
}
unsafe {
let mut ret = DirEntry {
entry: mem::zeroed(),
dir: self.clone(),
};
let mut entry_ptr = ptr::null_mut();
loop {
if readdir64_r(self.inner.dirp.0, &mut ret.entry, &mut entry_ptr) != 0 {
if entry_ptr.is_null() {
// We encountered an error (which will be returned in this iteration), but
// we also reached the end of the directory stream. The `end_of_stream`
// flag is enabled to make sure that we return `None` in the next iteration
// (instead of looping forever)
self.end_of_stream = true;
}
return Some(Err(Error::last_os_error()))
}
if entry_ptr.is_null() {
return None
}
if ret.name_bytes() != b"." && ret.name_bytes() != b".." {
return Some(Ok(ret))
}
}
}
}
}
impl Drop for Dir {
fn drop(&mut self) {
let r = unsafe { libc::closedir(self.0) };
debug_assert_eq!(r, 0);
}
}
impl DirEntry {
pub fn path(&self) -> PathBuf {
self.dir.inner.root.join(OsStr::from_bytes(self.name_bytes()))
}
std: Expand the area of std::fs This commit is an implementation of [RFC 1044][rfc] which adds additional surface area to the `std::fs` module. All new APIs are `#[unstable]` behind assorted feature names for each one. [rfc]: https://github.com/rust-lang/rfcs/pull/1044 The new APIs added are: * `fs::canonicalize` - bindings to `realpath` on unix and `GetFinalPathNameByHandle` on windows. * `fs::symlink_metadata` - similar to `lstat` on unix * `fs::FileType` and accessor methods as `is_{file,dir,symlink}` * `fs::Metadata::file_type` - accessor for the raw file type * `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows but requires a syscall on unix. * `fs::DirEntry::file_type` - access the file type which may not require a syscall on most platforms. * `fs::DirEntry::file_name` - access just the file name without leading components. * `fs::PathExt::symlink_metadata` - convenience method for the top-level function. * `fs::PathExt::canonicalize` - convenience method for the top-level function. * `fs::PathExt::read_link` - convenience method for the top-level function. * `fs::PathExt::read_dir` - convenience method for the top-level function. * `std::os::raw` - type definitions for raw OS/C types available on all platforms. * `std::os::$platform` - new modules have been added for all currently supported platforms (e.g. those more specific than just `unix`). * `std::os::$platform::raw` - platform-specific type definitions. These modules are populated with the bare essentials necessary for lowing I/O types into their raw representations, and currently largely consist of the `stat` definition for unix platforms. This commit also deprecates `Metadata::{modified, accessed}` in favor of inspecting the raw representations via the lowering methods of `Metadata`.
2015-04-16 06:21:13 +00:00
pub fn file_name(&self) -> OsString {
OsStr::from_bytes(self.name_bytes()).to_os_string()
}
#[cfg(any(target_os = "linux", target_os = "emscripten", target_os = "android"))]
pub fn metadata(&self) -> io::Result<FileAttr> {
let fd = cvt(unsafe {dirfd(self.dir.inner.dirp.0)})?;
let mut stat: stat64 = unsafe { mem::zeroed() };
cvt(unsafe {
2018-06-25 18:42:27 +00:00
fstatat64(fd, self.entry.d_name.as_ptr(), &mut stat, libc::AT_SYMLINK_NOFOLLOW)
})?;
2018-11-06 20:05:44 +00:00
Ok(FileAttr { stat })
}
#[cfg(not(any(target_os = "linux", target_os = "emscripten", target_os = "android")))]
std: Expand the area of std::fs This commit is an implementation of [RFC 1044][rfc] which adds additional surface area to the `std::fs` module. All new APIs are `#[unstable]` behind assorted feature names for each one. [rfc]: https://github.com/rust-lang/rfcs/pull/1044 The new APIs added are: * `fs::canonicalize` - bindings to `realpath` on unix and `GetFinalPathNameByHandle` on windows. * `fs::symlink_metadata` - similar to `lstat` on unix * `fs::FileType` and accessor methods as `is_{file,dir,symlink}` * `fs::Metadata::file_type` - accessor for the raw file type * `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows but requires a syscall on unix. * `fs::DirEntry::file_type` - access the file type which may not require a syscall on most platforms. * `fs::DirEntry::file_name` - access just the file name without leading components. * `fs::PathExt::symlink_metadata` - convenience method for the top-level function. * `fs::PathExt::canonicalize` - convenience method for the top-level function. * `fs::PathExt::read_link` - convenience method for the top-level function. * `fs::PathExt::read_dir` - convenience method for the top-level function. * `std::os::raw` - type definitions for raw OS/C types available on all platforms. * `std::os::$platform` - new modules have been added for all currently supported platforms (e.g. those more specific than just `unix`). * `std::os::$platform::raw` - platform-specific type definitions. These modules are populated with the bare essentials necessary for lowing I/O types into their raw representations, and currently largely consist of the `stat` definition for unix platforms. This commit also deprecates `Metadata::{modified, accessed}` in favor of inspecting the raw representations via the lowering methods of `Metadata`.
2015-04-16 06:21:13 +00:00
pub fn metadata(&self) -> io::Result<FileAttr> {
lstat(&self.path())
}
#[cfg(any(target_os = "solaris", target_os = "haiku", target_os = "hermit"))]
pub fn file_type(&self) -> io::Result<FileType> {
lstat(&self.path()).map(|m| m.file_type())
}
#[cfg(not(any(target_os = "solaris", target_os = "haiku", target_os = "hermit")))]
std: Expand the area of std::fs This commit is an implementation of [RFC 1044][rfc] which adds additional surface area to the `std::fs` module. All new APIs are `#[unstable]` behind assorted feature names for each one. [rfc]: https://github.com/rust-lang/rfcs/pull/1044 The new APIs added are: * `fs::canonicalize` - bindings to `realpath` on unix and `GetFinalPathNameByHandle` on windows. * `fs::symlink_metadata` - similar to `lstat` on unix * `fs::FileType` and accessor methods as `is_{file,dir,symlink}` * `fs::Metadata::file_type` - accessor for the raw file type * `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows but requires a syscall on unix. * `fs::DirEntry::file_type` - access the file type which may not require a syscall on most platforms. * `fs::DirEntry::file_name` - access just the file name without leading components. * `fs::PathExt::symlink_metadata` - convenience method for the top-level function. * `fs::PathExt::canonicalize` - convenience method for the top-level function. * `fs::PathExt::read_link` - convenience method for the top-level function. * `fs::PathExt::read_dir` - convenience method for the top-level function. * `std::os::raw` - type definitions for raw OS/C types available on all platforms. * `std::os::$platform` - new modules have been added for all currently supported platforms (e.g. those more specific than just `unix`). * `std::os::$platform::raw` - platform-specific type definitions. These modules are populated with the bare essentials necessary for lowing I/O types into their raw representations, and currently largely consist of the `stat` definition for unix platforms. This commit also deprecates `Metadata::{modified, accessed}` in favor of inspecting the raw representations via the lowering methods of `Metadata`.
2015-04-16 06:21:13 +00:00
pub fn file_type(&self) -> io::Result<FileType> {
match self.entry.d_type {
libc::DT_CHR => Ok(FileType { mode: libc::S_IFCHR }),
libc::DT_FIFO => Ok(FileType { mode: libc::S_IFIFO }),
libc::DT_LNK => Ok(FileType { mode: libc::S_IFLNK }),
libc::DT_REG => Ok(FileType { mode: libc::S_IFREG }),
libc::DT_SOCK => Ok(FileType { mode: libc::S_IFSOCK }),
libc::DT_DIR => Ok(FileType { mode: libc::S_IFDIR }),
libc::DT_BLK => Ok(FileType { mode: libc::S_IFBLK }),
_ => lstat(&self.path()).map(|m| m.file_type()),
std: Expand the area of std::fs This commit is an implementation of [RFC 1044][rfc] which adds additional surface area to the `std::fs` module. All new APIs are `#[unstable]` behind assorted feature names for each one. [rfc]: https://github.com/rust-lang/rfcs/pull/1044 The new APIs added are: * `fs::canonicalize` - bindings to `realpath` on unix and `GetFinalPathNameByHandle` on windows. * `fs::symlink_metadata` - similar to `lstat` on unix * `fs::FileType` and accessor methods as `is_{file,dir,symlink}` * `fs::Metadata::file_type` - accessor for the raw file type * `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows but requires a syscall on unix. * `fs::DirEntry::file_type` - access the file type which may not require a syscall on most platforms. * `fs::DirEntry::file_name` - access just the file name without leading components. * `fs::PathExt::symlink_metadata` - convenience method for the top-level function. * `fs::PathExt::canonicalize` - convenience method for the top-level function. * `fs::PathExt::read_link` - convenience method for the top-level function. * `fs::PathExt::read_dir` - convenience method for the top-level function. * `std::os::raw` - type definitions for raw OS/C types available on all platforms. * `std::os::$platform` - new modules have been added for all currently supported platforms (e.g. those more specific than just `unix`). * `std::os::$platform::raw` - platform-specific type definitions. These modules are populated with the bare essentials necessary for lowing I/O types into their raw representations, and currently largely consist of the `stat` definition for unix platforms. This commit also deprecates `Metadata::{modified, accessed}` in favor of inspecting the raw representations via the lowering methods of `Metadata`.
2015-04-16 06:21:13 +00:00
}
}
#[cfg(any(target_os = "macos",
target_os = "ios",
2016-01-21 16:30:22 +00:00
target_os = "linux",
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
target_os = "emscripten",
target_os = "android",
target_os = "solaris",
target_os = "haiku",
target_os = "l4re",
target_os = "fuchsia",
target_os = "hermit"))]
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
pub fn ino(&self) -> u64 {
self.entry.d_ino as u64
}
#[cfg(any(target_os = "freebsd",
target_os = "openbsd",
target_os = "netbsd",
target_os = "dragonfly"))]
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
pub fn ino(&self) -> u64 {
self.entry.d_fileno as u64
std: Expand the area of std::fs This commit is an implementation of [RFC 1044][rfc] which adds additional surface area to the `std::fs` module. All new APIs are `#[unstable]` behind assorted feature names for each one. [rfc]: https://github.com/rust-lang/rfcs/pull/1044 The new APIs added are: * `fs::canonicalize` - bindings to `realpath` on unix and `GetFinalPathNameByHandle` on windows. * `fs::symlink_metadata` - similar to `lstat` on unix * `fs::FileType` and accessor methods as `is_{file,dir,symlink}` * `fs::Metadata::file_type` - accessor for the raw file type * `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows but requires a syscall on unix. * `fs::DirEntry::file_type` - access the file type which may not require a syscall on most platforms. * `fs::DirEntry::file_name` - access just the file name without leading components. * `fs::PathExt::symlink_metadata` - convenience method for the top-level function. * `fs::PathExt::canonicalize` - convenience method for the top-level function. * `fs::PathExt::read_link` - convenience method for the top-level function. * `fs::PathExt::read_dir` - convenience method for the top-level function. * `std::os::raw` - type definitions for raw OS/C types available on all platforms. * `std::os::$platform` - new modules have been added for all currently supported platforms (e.g. those more specific than just `unix`). * `std::os::$platform::raw` - platform-specific type definitions. These modules are populated with the bare essentials necessary for lowing I/O types into their raw representations, and currently largely consist of the `stat` definition for unix platforms. This commit also deprecates `Metadata::{modified, accessed}` in favor of inspecting the raw representations via the lowering methods of `Metadata`.
2015-04-16 06:21:13 +00:00
}
#[cfg(any(target_os = "macos",
target_os = "ios",
2015-12-23 17:56:42 +00:00
target_os = "netbsd",
target_os = "openbsd",
target_os = "freebsd",
2019-05-13 07:13:07 +00:00
target_os = "dragonfly"))]
fn name_bytes(&self) -> &[u8] {
2019-02-10 19:23:21 +00:00
use crate::slice;
unsafe {
2019-02-10 19:23:21 +00:00
slice::from_raw_parts(self.entry.d_name.as_ptr() as *const u8,
self.entry.d_namlen as usize)
}
}
#[cfg(any(target_os = "android",
target_os = "linux",
target_os = "emscripten",
target_os = "l4re",
target_os = "haiku",
target_os = "hermit"))]
fn name_bytes(&self) -> &[u8] {
unsafe {
CStr::from_ptr(self.entry.d_name.as_ptr()).to_bytes()
}
}
#[cfg(any(target_os = "solaris",
target_os = "fuchsia"))]
2016-01-21 16:30:22 +00:00
fn name_bytes(&self) -> &[u8] {
&*self.name
}
}
impl OpenOptions {
pub fn new() -> OpenOptions {
OpenOptions {
// generic
read: false,
write: false,
append: false,
truncate: false,
create: false,
create_new: false,
// system-specific
custom_flags: 0,
2015-02-11 22:40:09 +00:00
mode: 0o666,
}
}
pub fn read(&mut self, read: bool) { self.read = read; }
pub fn write(&mut self, write: bool) { self.write = write; }
pub fn append(&mut self, append: bool) { self.append = append; }
pub fn truncate(&mut self, truncate: bool) { self.truncate = truncate; }
pub fn create(&mut self, create: bool) { self.create = create; }
pub fn create_new(&mut self, create_new: bool) { self.create_new = create_new; }
pub fn custom_flags(&mut self, flags: i32) { self.custom_flags = flags; }
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
pub fn mode(&mut self, mode: u32) { self.mode = mode as mode_t; }
fn get_access_mode(&self) -> io::Result<c_int> {
match (self.read, self.write, self.append) {
(true, false, false) => Ok(libc::O_RDONLY),
(false, true, false) => Ok(libc::O_WRONLY),
(true, true, false) => Ok(libc::O_RDWR),
(false, _, true) => Ok(libc::O_WRONLY | libc::O_APPEND),
(true, _, true) => Ok(libc::O_RDWR | libc::O_APPEND),
(false, false, false) => Err(Error::from_raw_os_error(libc::EINVAL)),
}
}
fn get_creation_mode(&self) -> io::Result<c_int> {
match (self.write, self.append) {
2016-01-15 18:04:53 +00:00
(true, false) => {}
(false, false) =>
if self.truncate || self.create || self.create_new {
return Err(Error::from_raw_os_error(libc::EINVAL));
},
(_, true) =>
if self.truncate && !self.create_new {
return Err(Error::from_raw_os_error(libc::EINVAL));
},
}
Ok(match (self.create, self.truncate, self.create_new) {
(false, false, false) => 0,
(true, false, false) => libc::O_CREAT,
(false, true, false) => libc::O_TRUNC,
(true, true, false) => libc::O_CREAT | libc::O_TRUNC,
(_, _, true) => libc::O_CREAT | libc::O_EXCL,
})
}
}
impl File {
pub fn open(path: &Path, opts: &OpenOptions) -> io::Result<File> {
let path = cstr(path)?;
File::open_c(&path, opts)
}
pub fn open_c(path: &CStr, opts: &OpenOptions) -> io::Result<File> {
let flags = libc::O_CLOEXEC |
opts.get_access_mode()? |
opts.get_creation_mode()? |
(opts.custom_flags as c_int & !libc::O_ACCMODE);
let fd = cvt_r(|| unsafe {
2016-02-15 00:27:18 +00:00
open64(path.as_ptr(), flags, opts.mode as c_int)
})?;
let fd = FileDesc::new(fd);
// Currently the standard library supports Linux 2.6.18 which did not
// have the O_CLOEXEC flag (passed above). If we're running on an older
// Linux kernel then the flag is just ignored by the OS. After we open
// the first file, we check whether it has CLOEXEC set. If it doesn't,
// we will explicitly ask for a CLOEXEC fd for every further file we
// open, if it does, we will skip that step.
//
// The CLOEXEC flag, however, is supported on versions of macOS/BSD/etc
// that we support, so we only do this on Linux currently.
#[cfg(target_os = "linux")]
fn ensure_cloexec(fd: &FileDesc) -> io::Result<()> {
2019-02-10 19:23:21 +00:00
use crate::sync::atomic::{AtomicUsize, Ordering};
const OPEN_CLOEXEC_UNKNOWN: usize = 0;
const OPEN_CLOEXEC_SUPPORTED: usize = 1;
const OPEN_CLOEXEC_NOTSUPPORTED: usize = 2;
static OPEN_CLOEXEC: AtomicUsize = AtomicUsize::new(OPEN_CLOEXEC_UNKNOWN);
let need_to_set;
match OPEN_CLOEXEC.load(Ordering::Relaxed) {
OPEN_CLOEXEC_UNKNOWN => {
need_to_set = !fd.get_cloexec()?;
OPEN_CLOEXEC.store(if need_to_set {
OPEN_CLOEXEC_NOTSUPPORTED
} else {
OPEN_CLOEXEC_SUPPORTED
}, Ordering::Relaxed);
},
OPEN_CLOEXEC_SUPPORTED => need_to_set = false,
OPEN_CLOEXEC_NOTSUPPORTED => need_to_set = true,
_ => unreachable!(),
}
if need_to_set {
fd.set_cloexec()?;
}
Ok(())
}
#[cfg(not(target_os = "linux"))]
fn ensure_cloexec(_: &FileDesc) -> io::Result<()> {
Ok(())
}
ensure_cloexec(&fd)?;
Ok(File(fd))
}
pub fn file_attr(&self) -> io::Result<FileAttr> {
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
let mut stat: stat64 = unsafe { mem::zeroed() };
cvt(unsafe {
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
fstat64(self.0.raw(), &mut stat)
})?;
2018-11-06 20:05:44 +00:00
Ok(FileAttr { stat })
}
pub fn fsync(&self) -> io::Result<()> {
cvt_r(|| unsafe { os_fsync(self.0.raw()) })?;
return Ok(());
#[cfg(any(target_os = "macos", target_os = "ios"))]
unsafe fn os_fsync(fd: c_int) -> c_int {
libc::fcntl(fd, libc::F_FULLFSYNC)
}
#[cfg(not(any(target_os = "macos", target_os = "ios")))]
unsafe fn os_fsync(fd: c_int) -> c_int { libc::fsync(fd) }
}
pub fn datasync(&self) -> io::Result<()> {
cvt_r(|| unsafe { os_datasync(self.0.raw()) })?;
return Ok(());
#[cfg(any(target_os = "macos", target_os = "ios"))]
unsafe fn os_datasync(fd: c_int) -> c_int {
libc::fcntl(fd, libc::F_FULLFSYNC)
}
#[cfg(target_os = "linux")]
unsafe fn os_datasync(fd: c_int) -> c_int { libc::fdatasync(fd) }
#[cfg(not(any(target_os = "macos",
target_os = "ios",
target_os = "linux")))]
unsafe fn os_datasync(fd: c_int) -> c_int { libc::fsync(fd) }
}
pub fn truncate(&self, size: u64) -> io::Result<()> {
#[cfg(target_os = "android")]
2019-02-10 19:23:21 +00:00
return crate::sys::android::ftruncate64(self.0.raw(), size);
#[cfg(not(target_os = "android"))]
return cvt_r(|| unsafe {
2016-02-15 00:09:57 +00:00
ftruncate64(self.0.raw(), size as off64_t)
}).map(|_| ());
}
pub fn read(&self, buf: &mut [u8]) -> io::Result<usize> {
self.0.read(buf)
}
pub fn read_vectored(&self, bufs: &mut [IoSliceMut<'_>]) -> io::Result<usize> {
self.0.read_vectored(bufs)
}
pub fn read_at(&self, buf: &mut [u8], offset: u64) -> io::Result<usize> {
self.0.read_at(buf, offset)
}
pub fn write(&self, buf: &[u8]) -> io::Result<usize> {
self.0.write(buf)
}
pub fn write_vectored(&self, bufs: &[IoSlice<'_>]) -> io::Result<usize> {
self.0.write_vectored(bufs)
}
pub fn write_at(&self, buf: &[u8], offset: u64) -> io::Result<usize> {
self.0.write_at(buf, offset)
}
pub fn flush(&self) -> io::Result<()> { Ok(()) }
pub fn seek(&self, pos: SeekFrom) -> io::Result<u64> {
let (whence, pos) = match pos {
// Casting to `i64` is fine, too large values will end up as
// negative which will cause an error in `lseek64`.
SeekFrom::Start(off) => (libc::SEEK_SET, off as i64),
SeekFrom::End(off) => (libc::SEEK_END, off),
SeekFrom::Current(off) => (libc::SEEK_CUR, off),
};
#[cfg(target_os = "emscripten")]
let pos = pos as i32;
let n = cvt(unsafe { lseek64(self.0.raw(), pos, whence) })?;
Ok(n as u64)
}
2016-01-21 05:24:23 +00:00
pub fn duplicate(&self) -> io::Result<File> {
self.0.duplicate().map(File)
}
pub fn fd(&self) -> &FileDesc { &self.0 }
pub fn into_fd(self) -> FileDesc { self.0 }
pub fn set_permissions(&self, perm: FilePermissions) -> io::Result<()> {
cvt_r(|| unsafe { libc::fchmod(self.0.raw(), perm.mode) })?;
Ok(())
}
}
impl DirBuilder {
pub fn new() -> DirBuilder {
DirBuilder { mode: 0o777 }
}
pub fn mkdir(&self, p: &Path) -> io::Result<()> {
let p = cstr(p)?;
cvt(unsafe { libc::mkdir(p.as_ptr(), self.mode) })?;
Ok(())
}
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
pub fn set_mode(&mut self, mode: u32) {
self.mode = mode as mode_t;
}
}
std: Implement CString-related RFCs This commit is an implementation of [RFC 592][r592] and [RFC 840][r840]. These two RFCs tweak the behavior of `CString` and add a new `CStr` unsized slice type to the module. [r592]: https://github.com/rust-lang/rfcs/blob/master/text/0592-c-str-deref.md [r840]: https://github.com/rust-lang/rfcs/blob/master/text/0840-no-panic-in-c-string.md The new `CStr` type is only constructable via two methods: 1. By `deref`'ing from a `CString` 2. Unsafely via `CStr::from_ptr` The purpose of `CStr` is to be an unsized type which is a thin pointer to a `libc::c_char` (currently it is a fat pointer slice due to implementation limitations). Strings from C can be safely represented with a `CStr` and an appropriate lifetime as well. Consumers of `&CString` should now consume `&CStr` instead to allow producers to pass in C-originating strings instead of just Rust-allocated strings. A new constructor was added to `CString`, `new`, which takes `T: IntoBytes` instead of separate `from_slice` and `from_vec` methods (both have been deprecated in favor of `new`). The `new` method returns a `Result` instead of panicking. The error variant contains the relevant information about where the error happened and bytes (if present). Conversions are provided to the `io::Error` and `old_io::IoError` types via the `FromError` trait which translate to `InvalidInput`. This is a breaking change due to the modification of existing `#[unstable]` APIs and new deprecation, and more detailed information can be found in the two RFCs. Notable breakage includes: * All construction of `CString` now needs to use `new` and handle the outgoing `Result`. * Usage of `CString` as a byte slice now explicitly needs a `.as_bytes()` call. * The `as_slice*` methods have been removed in favor of just having the `as_bytes*` methods. Closes #22469 Closes #22470 [breaking-change]
2015-02-18 06:47:40 +00:00
fn cstr(path: &Path) -> io::Result<CString> {
Ok(CString::new(path.as_os_str().as_bytes())?)
}
impl FromInner<c_int> for File {
fn from_inner(fd: c_int) -> File {
File(FileDesc::new(fd))
}
}
impl fmt::Debug for File {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
#[cfg(target_os = "linux")]
fn get_path(fd: c_int) -> Option<PathBuf> {
let mut p = PathBuf::from("/proc/self/fd");
p.push(&fd.to_string());
readlink(&p).ok()
}
#[cfg(target_os = "macos")]
fn get_path(fd: c_int) -> Option<PathBuf> {
Reduce the reliance on `PATH_MAX` - Rewrite `std::sys::fs::readlink` not to rely on `PATH_MAX` It currently has the following problems: 1. It uses `_PC_NAME_MAX` to query the maximum length of a file path in the underlying system. However, the meaning of the constant is the maximum length of *a path component*, not a full path. The correct constant should be `_PC_PATH_MAX`. 2. `pathconf` *may* fail if the referred file does not exist. This can be problematic if the file which the symbolic link points to does not exist, but the link itself does exist. In this case, the current implementation resorts to the hard-coded value of `1024`, which is not ideal. 3. There may exist a platform where there is no limit on file path lengths in general. That's the reaon why GNU Hurd doesn't define `PATH_MAX` at all, in addition to having `pathconf` always returning `-1`. In these platforms, the content of the symbolic link can be silently truncated if the length exceeds the hard-coded limit mentioned above. 4. The value obtained by `pathconf` may be outdated at the point of actually calling `readlink`. This is inherently racy. This commit introduces a loop that gradually increases the length of the buffer passed to `readlink`, eliminating the need of `pathconf`. - Remove the arbitrary memory limit of `std::sys::fs::realpath` As per POSIX 2013, `realpath` will return a malloc'ed buffer if the second argument is a null pointer.[1] [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html - Comment on functions that are still using `PATH_MAX` There are some functions that only work in terms of `PATH_MAX`, such as `F_GETPATH` in OS X. Comments on them for posterity.
2015-08-19 04:11:40 +00:00
// FIXME: The use of PATH_MAX is generally not encouraged, but it
// is inevitable in this case because macOS defines `fcntl` with
Reduce the reliance on `PATH_MAX` - Rewrite `std::sys::fs::readlink` not to rely on `PATH_MAX` It currently has the following problems: 1. It uses `_PC_NAME_MAX` to query the maximum length of a file path in the underlying system. However, the meaning of the constant is the maximum length of *a path component*, not a full path. The correct constant should be `_PC_PATH_MAX`. 2. `pathconf` *may* fail if the referred file does not exist. This can be problematic if the file which the symbolic link points to does not exist, but the link itself does exist. In this case, the current implementation resorts to the hard-coded value of `1024`, which is not ideal. 3. There may exist a platform where there is no limit on file path lengths in general. That's the reaon why GNU Hurd doesn't define `PATH_MAX` at all, in addition to having `pathconf` always returning `-1`. In these platforms, the content of the symbolic link can be silently truncated if the length exceeds the hard-coded limit mentioned above. 4. The value obtained by `pathconf` may be outdated at the point of actually calling `readlink`. This is inherently racy. This commit introduces a loop that gradually increases the length of the buffer passed to `readlink`, eliminating the need of `pathconf`. - Remove the arbitrary memory limit of `std::sys::fs::realpath` As per POSIX 2013, `realpath` will return a malloc'ed buffer if the second argument is a null pointer.[1] [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html - Comment on functions that are still using `PATH_MAX` There are some functions that only work in terms of `PATH_MAX`, such as `F_GETPATH` in OS X. Comments on them for posterity.
2015-08-19 04:11:40 +00:00
// `F_GETPATH` in terms of `MAXPATHLEN`, and there are no
// alternatives. If a better method is invented, it should be used
// instead.
let mut buf = vec![0;libc::PATH_MAX as usize];
let n = unsafe { libc::fcntl(fd, libc::F_GETPATH, buf.as_ptr()) };
if n == -1 {
return None;
}
let l = buf.iter().position(|&c| c == 0).unwrap();
buf.truncate(l as usize);
Reduce the reliance on `PATH_MAX` - Rewrite `std::sys::fs::readlink` not to rely on `PATH_MAX` It currently has the following problems: 1. It uses `_PC_NAME_MAX` to query the maximum length of a file path in the underlying system. However, the meaning of the constant is the maximum length of *a path component*, not a full path. The correct constant should be `_PC_PATH_MAX`. 2. `pathconf` *may* fail if the referred file does not exist. This can be problematic if the file which the symbolic link points to does not exist, but the link itself does exist. In this case, the current implementation resorts to the hard-coded value of `1024`, which is not ideal. 3. There may exist a platform where there is no limit on file path lengths in general. That's the reaon why GNU Hurd doesn't define `PATH_MAX` at all, in addition to having `pathconf` always returning `-1`. In these platforms, the content of the symbolic link can be silently truncated if the length exceeds the hard-coded limit mentioned above. 4. The value obtained by `pathconf` may be outdated at the point of actually calling `readlink`. This is inherently racy. This commit introduces a loop that gradually increases the length of the buffer passed to `readlink`, eliminating the need of `pathconf`. - Remove the arbitrary memory limit of `std::sys::fs::realpath` As per POSIX 2013, `realpath` will return a malloc'ed buffer if the second argument is a null pointer.[1] [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html - Comment on functions that are still using `PATH_MAX` There are some functions that only work in terms of `PATH_MAX`, such as `F_GETPATH` in OS X. Comments on them for posterity.
2015-08-19 04:11:40 +00:00
buf.shrink_to_fit();
Some(PathBuf::from(OsString::from_vec(buf)))
}
#[cfg(not(any(target_os = "linux", target_os = "macos")))]
fn get_path(_fd: c_int) -> Option<PathBuf> {
// FIXME(#24570): implement this for other Unix platforms
None
}
#[cfg(any(target_os = "linux", target_os = "macos"))]
fn get_mode(fd: c_int) -> Option<(bool, bool)> {
let mode = unsafe { libc::fcntl(fd, libc::F_GETFL) };
if mode == -1 {
return None;
}
match mode & libc::O_ACCMODE {
libc::O_RDONLY => Some((true, false)),
libc::O_RDWR => Some((true, true)),
libc::O_WRONLY => Some((false, true)),
_ => None
}
}
#[cfg(not(any(target_os = "linux", target_os = "macos")))]
fn get_mode(_fd: c_int) -> Option<(bool, bool)> {
// FIXME(#24570): implement this for other Unix platforms
None
}
let fd = self.0.raw();
let mut b = f.debug_struct("File");
b.field("fd", &fd);
if let Some(path) = get_path(fd) {
b.field("path", &path);
}
if let Some((read, write)) = get_mode(fd) {
b.field("read", &read).field("write", &write);
}
b.finish()
}
}
pub fn readdir(p: &Path) -> io::Result<ReadDir> {
let root = p.to_path_buf();
let p = cstr(p)?;
unsafe {
let ptr = libc::opendir(p.as_ptr());
if ptr.is_null() {
Err(Error::last_os_error())
} else {
let inner = InnerReadDir { dirp: Dir(ptr), root };
Ok(ReadDir{
inner: Arc::new(inner),
end_of_stream: false,
})
}
}
}
pub fn unlink(p: &Path) -> io::Result<()> {
let p = cstr(p)?;
cvt(unsafe { libc::unlink(p.as_ptr()) })?;
Ok(())
}
pub fn rename(old: &Path, new: &Path) -> io::Result<()> {
let old = cstr(old)?;
let new = cstr(new)?;
cvt(unsafe { libc::rename(old.as_ptr(), new.as_ptr()) })?;
Ok(())
}
pub fn set_perm(p: &Path, perm: FilePermissions) -> io::Result<()> {
let p = cstr(p)?;
cvt_r(|| unsafe { libc::chmod(p.as_ptr(), perm.mode) })?;
Ok(())
}
pub fn rmdir(p: &Path) -> io::Result<()> {
let p = cstr(p)?;
cvt(unsafe { libc::rmdir(p.as_ptr()) })?;
Ok(())
}
pub fn readlink(p: &Path) -> io::Result<PathBuf> {
let c_path = cstr(p)?;
let p = c_path.as_ptr();
Reduce the reliance on `PATH_MAX` - Rewrite `std::sys::fs::readlink` not to rely on `PATH_MAX` It currently has the following problems: 1. It uses `_PC_NAME_MAX` to query the maximum length of a file path in the underlying system. However, the meaning of the constant is the maximum length of *a path component*, not a full path. The correct constant should be `_PC_PATH_MAX`. 2. `pathconf` *may* fail if the referred file does not exist. This can be problematic if the file which the symbolic link points to does not exist, but the link itself does exist. In this case, the current implementation resorts to the hard-coded value of `1024`, which is not ideal. 3. There may exist a platform where there is no limit on file path lengths in general. That's the reaon why GNU Hurd doesn't define `PATH_MAX` at all, in addition to having `pathconf` always returning `-1`. In these platforms, the content of the symbolic link can be silently truncated if the length exceeds the hard-coded limit mentioned above. 4. The value obtained by `pathconf` may be outdated at the point of actually calling `readlink`. This is inherently racy. This commit introduces a loop that gradually increases the length of the buffer passed to `readlink`, eliminating the need of `pathconf`. - Remove the arbitrary memory limit of `std::sys::fs::realpath` As per POSIX 2013, `realpath` will return a malloc'ed buffer if the second argument is a null pointer.[1] [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html - Comment on functions that are still using `PATH_MAX` There are some functions that only work in terms of `PATH_MAX`, such as `F_GETPATH` in OS X. Comments on them for posterity.
2015-08-19 04:11:40 +00:00
let mut buf = Vec::with_capacity(256);
loop {
let buf_read = cvt(unsafe {
libc::readlink(p, buf.as_mut_ptr() as *mut _, buf.capacity())
})? as usize;
Reduce the reliance on `PATH_MAX` - Rewrite `std::sys::fs::readlink` not to rely on `PATH_MAX` It currently has the following problems: 1. It uses `_PC_NAME_MAX` to query the maximum length of a file path in the underlying system. However, the meaning of the constant is the maximum length of *a path component*, not a full path. The correct constant should be `_PC_PATH_MAX`. 2. `pathconf` *may* fail if the referred file does not exist. This can be problematic if the file which the symbolic link points to does not exist, but the link itself does exist. In this case, the current implementation resorts to the hard-coded value of `1024`, which is not ideal. 3. There may exist a platform where there is no limit on file path lengths in general. That's the reaon why GNU Hurd doesn't define `PATH_MAX` at all, in addition to having `pathconf` always returning `-1`. In these platforms, the content of the symbolic link can be silently truncated if the length exceeds the hard-coded limit mentioned above. 4. The value obtained by `pathconf` may be outdated at the point of actually calling `readlink`. This is inherently racy. This commit introduces a loop that gradually increases the length of the buffer passed to `readlink`, eliminating the need of `pathconf`. - Remove the arbitrary memory limit of `std::sys::fs::realpath` As per POSIX 2013, `realpath` will return a malloc'ed buffer if the second argument is a null pointer.[1] [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html - Comment on functions that are still using `PATH_MAX` There are some functions that only work in terms of `PATH_MAX`, such as `F_GETPATH` in OS X. Comments on them for posterity.
2015-08-19 04:11:40 +00:00
unsafe { buf.set_len(buf_read); }
if buf_read != buf.capacity() {
buf.shrink_to_fit();
return Ok(PathBuf::from(OsString::from_vec(buf)));
}
// Trigger the internal buffer resizing logic of `Vec` by requiring
// more space than the current capacity. The length is guaranteed to be
// the same as the capacity due to the if statement above.
buf.reserve(1);
}
}
pub fn symlink(src: &Path, dst: &Path) -> io::Result<()> {
let src = cstr(src)?;
let dst = cstr(dst)?;
cvt(unsafe { libc::symlink(src.as_ptr(), dst.as_ptr()) })?;
Ok(())
}
pub fn link(src: &Path, dst: &Path) -> io::Result<()> {
let src = cstr(src)?;
let dst = cstr(dst)?;
cvt(unsafe { libc::link(src.as_ptr(), dst.as_ptr()) })?;
Ok(())
}
pub fn stat(p: &Path) -> io::Result<FileAttr> {
let p = cstr(p)?;
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
let mut stat: stat64 = unsafe { mem::zeroed() };
cvt(unsafe {
stat64(p.as_ptr(), &mut stat)
})?;
2018-11-06 20:05:44 +00:00
Ok(FileAttr { stat })
}
pub fn lstat(p: &Path) -> io::Result<FileAttr> {
let p = cstr(p)?;
std: Deprecate all std::os::*::raw types This commit is an implementation of [RFC 1415][rfc] which deprecates all types in the `std::os::*::raw` modules. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md Many of the types in these modules don't actually have a canonical platform representation, for example the definition of `stat` on 32-bit Linux will change depending on whether C code is compiled with LFS support or not. Unfortunately the current types in `std::os::*::raw` are billed as "compatible with C", which in light of this means it isn't really possible. To make matters worse, platforms like Android sometimes define these types as *smaller* than the way they're actually represented in the `stat` structure itself. This means that when methods like `DirEntry::ino` are called on Android the result may be truncated as we're tied to returning a `ino_t` type, not the underlying type. The commit here incorporates two backwards-compatible components: * Deprecate all `raw` types that aren't in `std::os::raw` * Expand the `std::os::*::fs::MetadataExt` trait on all platforms for method accessors of all fields. The fields now returned widened types which are the same across platforms (consistency across platforms is not required, however, it's just convenient). and two also backwards-incompatible components: * Change the definition of all `std::os::*::raw` type aliases to correspond to the newly widened types that are being returned on each platform. * Change the definition of `std::os::*::raw::stat` on Linux to match the LFS definitions rather than the standard ones. The breaking changes here will specifically break code that assumes that `libc` and `std` agree on the definition of `std::os::*::raw` types, or that the `std` types are faithful representations of the types in C. An [audit] has been performed of crates.io to determine the fallout which was determined two be minimal, with the two found cases of breakage having been fixed now. [audit]: https://github.com/rust-lang/rfcs/pull/1415#issuecomment-180645582 --- Ok, so after all that, we're finally able to support LFS on Linux! This commit then simultaneously starts using `stat64` and friends on Linux to ensure that we can open >4GB files on 32-bit Linux. Yay! Closes #28978 Closes #30050 Closes #31549
2016-02-05 01:16:47 +00:00
let mut stat: stat64 = unsafe { mem::zeroed() };
cvt(unsafe {
lstat64(p.as_ptr(), &mut stat)
})?;
2018-11-06 20:05:44 +00:00
Ok(FileAttr { stat })
}
std: Expand the area of std::fs This commit is an implementation of [RFC 1044][rfc] which adds additional surface area to the `std::fs` module. All new APIs are `#[unstable]` behind assorted feature names for each one. [rfc]: https://github.com/rust-lang/rfcs/pull/1044 The new APIs added are: * `fs::canonicalize` - bindings to `realpath` on unix and `GetFinalPathNameByHandle` on windows. * `fs::symlink_metadata` - similar to `lstat` on unix * `fs::FileType` and accessor methods as `is_{file,dir,symlink}` * `fs::Metadata::file_type` - accessor for the raw file type * `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows but requires a syscall on unix. * `fs::DirEntry::file_type` - access the file type which may not require a syscall on most platforms. * `fs::DirEntry::file_name` - access just the file name without leading components. * `fs::PathExt::symlink_metadata` - convenience method for the top-level function. * `fs::PathExt::canonicalize` - convenience method for the top-level function. * `fs::PathExt::read_link` - convenience method for the top-level function. * `fs::PathExt::read_dir` - convenience method for the top-level function. * `std::os::raw` - type definitions for raw OS/C types available on all platforms. * `std::os::$platform` - new modules have been added for all currently supported platforms (e.g. those more specific than just `unix`). * `std::os::$platform::raw` - platform-specific type definitions. These modules are populated with the bare essentials necessary for lowing I/O types into their raw representations, and currently largely consist of the `stat` definition for unix platforms. This commit also deprecates `Metadata::{modified, accessed}` in favor of inspecting the raw representations via the lowering methods of `Metadata`.
2015-04-16 06:21:13 +00:00
pub fn canonicalize(p: &Path) -> io::Result<PathBuf> {
let path = CString::new(p.as_os_str().as_bytes())?;
Reduce the reliance on `PATH_MAX` - Rewrite `std::sys::fs::readlink` not to rely on `PATH_MAX` It currently has the following problems: 1. It uses `_PC_NAME_MAX` to query the maximum length of a file path in the underlying system. However, the meaning of the constant is the maximum length of *a path component*, not a full path. The correct constant should be `_PC_PATH_MAX`. 2. `pathconf` *may* fail if the referred file does not exist. This can be problematic if the file which the symbolic link points to does not exist, but the link itself does exist. In this case, the current implementation resorts to the hard-coded value of `1024`, which is not ideal. 3. There may exist a platform where there is no limit on file path lengths in general. That's the reaon why GNU Hurd doesn't define `PATH_MAX` at all, in addition to having `pathconf` always returning `-1`. In these platforms, the content of the symbolic link can be silently truncated if the length exceeds the hard-coded limit mentioned above. 4. The value obtained by `pathconf` may be outdated at the point of actually calling `readlink`. This is inherently racy. This commit introduces a loop that gradually increases the length of the buffer passed to `readlink`, eliminating the need of `pathconf`. - Remove the arbitrary memory limit of `std::sys::fs::realpath` As per POSIX 2013, `realpath` will return a malloc'ed buffer if the second argument is a null pointer.[1] [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html - Comment on functions that are still using `PATH_MAX` There are some functions that only work in terms of `PATH_MAX`, such as `F_GETPATH` in OS X. Comments on them for posterity.
2015-08-19 04:11:40 +00:00
let buf;
std: Expand the area of std::fs This commit is an implementation of [RFC 1044][rfc] which adds additional surface area to the `std::fs` module. All new APIs are `#[unstable]` behind assorted feature names for each one. [rfc]: https://github.com/rust-lang/rfcs/pull/1044 The new APIs added are: * `fs::canonicalize` - bindings to `realpath` on unix and `GetFinalPathNameByHandle` on windows. * `fs::symlink_metadata` - similar to `lstat` on unix * `fs::FileType` and accessor methods as `is_{file,dir,symlink}` * `fs::Metadata::file_type` - accessor for the raw file type * `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows but requires a syscall on unix. * `fs::DirEntry::file_type` - access the file type which may not require a syscall on most platforms. * `fs::DirEntry::file_name` - access just the file name without leading components. * `fs::PathExt::symlink_metadata` - convenience method for the top-level function. * `fs::PathExt::canonicalize` - convenience method for the top-level function. * `fs::PathExt::read_link` - convenience method for the top-level function. * `fs::PathExt::read_dir` - convenience method for the top-level function. * `std::os::raw` - type definitions for raw OS/C types available on all platforms. * `std::os::$platform` - new modules have been added for all currently supported platforms (e.g. those more specific than just `unix`). * `std::os::$platform::raw` - platform-specific type definitions. These modules are populated with the bare essentials necessary for lowing I/O types into their raw representations, and currently largely consist of the `stat` definition for unix platforms. This commit also deprecates `Metadata::{modified, accessed}` in favor of inspecting the raw representations via the lowering methods of `Metadata`.
2015-04-16 06:21:13 +00:00
unsafe {
let r = libc::realpath(path.as_ptr(), ptr::null_mut());
std: Expand the area of std::fs This commit is an implementation of [RFC 1044][rfc] which adds additional surface area to the `std::fs` module. All new APIs are `#[unstable]` behind assorted feature names for each one. [rfc]: https://github.com/rust-lang/rfcs/pull/1044 The new APIs added are: * `fs::canonicalize` - bindings to `realpath` on unix and `GetFinalPathNameByHandle` on windows. * `fs::symlink_metadata` - similar to `lstat` on unix * `fs::FileType` and accessor methods as `is_{file,dir,symlink}` * `fs::Metadata::file_type` - accessor for the raw file type * `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows but requires a syscall on unix. * `fs::DirEntry::file_type` - access the file type which may not require a syscall on most platforms. * `fs::DirEntry::file_name` - access just the file name without leading components. * `fs::PathExt::symlink_metadata` - convenience method for the top-level function. * `fs::PathExt::canonicalize` - convenience method for the top-level function. * `fs::PathExt::read_link` - convenience method for the top-level function. * `fs::PathExt::read_dir` - convenience method for the top-level function. * `std::os::raw` - type definitions for raw OS/C types available on all platforms. * `std::os::$platform` - new modules have been added for all currently supported platforms (e.g. those more specific than just `unix`). * `std::os::$platform::raw` - platform-specific type definitions. These modules are populated with the bare essentials necessary for lowing I/O types into their raw representations, and currently largely consist of the `stat` definition for unix platforms. This commit also deprecates `Metadata::{modified, accessed}` in favor of inspecting the raw representations via the lowering methods of `Metadata`.
2015-04-16 06:21:13 +00:00
if r.is_null() {
return Err(io::Error::last_os_error())
}
Reduce the reliance on `PATH_MAX` - Rewrite `std::sys::fs::readlink` not to rely on `PATH_MAX` It currently has the following problems: 1. It uses `_PC_NAME_MAX` to query the maximum length of a file path in the underlying system. However, the meaning of the constant is the maximum length of *a path component*, not a full path. The correct constant should be `_PC_PATH_MAX`. 2. `pathconf` *may* fail if the referred file does not exist. This can be problematic if the file which the symbolic link points to does not exist, but the link itself does exist. In this case, the current implementation resorts to the hard-coded value of `1024`, which is not ideal. 3. There may exist a platform where there is no limit on file path lengths in general. That's the reaon why GNU Hurd doesn't define `PATH_MAX` at all, in addition to having `pathconf` always returning `-1`. In these platforms, the content of the symbolic link can be silently truncated if the length exceeds the hard-coded limit mentioned above. 4. The value obtained by `pathconf` may be outdated at the point of actually calling `readlink`. This is inherently racy. This commit introduces a loop that gradually increases the length of the buffer passed to `readlink`, eliminating the need of `pathconf`. - Remove the arbitrary memory limit of `std::sys::fs::realpath` As per POSIX 2013, `realpath` will return a malloc'ed buffer if the second argument is a null pointer.[1] [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html - Comment on functions that are still using `PATH_MAX` There are some functions that only work in terms of `PATH_MAX`, such as `F_GETPATH` in OS X. Comments on them for posterity.
2015-08-19 04:11:40 +00:00
buf = CStr::from_ptr(r).to_bytes().to_vec();
libc::free(r as *mut _);
std: Expand the area of std::fs This commit is an implementation of [RFC 1044][rfc] which adds additional surface area to the `std::fs` module. All new APIs are `#[unstable]` behind assorted feature names for each one. [rfc]: https://github.com/rust-lang/rfcs/pull/1044 The new APIs added are: * `fs::canonicalize` - bindings to `realpath` on unix and `GetFinalPathNameByHandle` on windows. * `fs::symlink_metadata` - similar to `lstat` on unix * `fs::FileType` and accessor methods as `is_{file,dir,symlink}` * `fs::Metadata::file_type` - accessor for the raw file type * `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows but requires a syscall on unix. * `fs::DirEntry::file_type` - access the file type which may not require a syscall on most platforms. * `fs::DirEntry::file_name` - access just the file name without leading components. * `fs::PathExt::symlink_metadata` - convenience method for the top-level function. * `fs::PathExt::canonicalize` - convenience method for the top-level function. * `fs::PathExt::read_link` - convenience method for the top-level function. * `fs::PathExt::read_dir` - convenience method for the top-level function. * `std::os::raw` - type definitions for raw OS/C types available on all platforms. * `std::os::$platform` - new modules have been added for all currently supported platforms (e.g. those more specific than just `unix`). * `std::os::$platform::raw` - platform-specific type definitions. These modules are populated with the bare essentials necessary for lowing I/O types into their raw representations, and currently largely consist of the `stat` definition for unix platforms. This commit also deprecates `Metadata::{modified, accessed}` in favor of inspecting the raw representations via the lowering methods of `Metadata`.
2015-04-16 06:21:13 +00:00
}
Ok(PathBuf::from(OsString::from_vec(buf)))
}
fn open_from(from: &Path) -> io::Result<(crate::fs::File, crate::fs::Metadata)> {
use crate::fs::File;
let reader = File::open(from)?;
let metadata = reader.metadata()?;
if !metadata.is_file() {
return Err(Error::new(
ErrorKind::InvalidInput,
"the source path is not an existing regular file",
));
}
Ok((reader, metadata))
}
fn open_to_and_set_permissions(
to: &Path,
reader_metadata: crate::fs::Metadata,
) -> io::Result<(crate::fs::File, crate::fs::Metadata)> {
use crate::fs::OpenOptions;
use crate::os::unix::fs::{OpenOptionsExt, PermissionsExt};
let perm = reader_metadata.permissions();
let writer = OpenOptions::new()
// create the file with the correct mode right away
.mode(perm.mode())
.write(true)
.create(true)
.truncate(true)
.open(to)?;
let writer_metadata = writer.metadata()?;
if writer_metadata.is_file() {
// Set the correct file permissions, in case the file already existed.
// Don't set the permissions on already existing non-files like
// pipes/FIFOs or device nodes.
writer.set_permissions(perm)?;
}
Ok((writer, writer_metadata))
}
#[cfg(not(any(target_os = "linux",
target_os = "android",
target_os = "macos",
target_os = "ios")))]
pub fn copy(from: &Path, to: &Path) -> io::Result<u64> {
let (mut reader, reader_metadata) = open_from(from)?;
let (mut writer, _) = open_to_and_set_permissions(to, reader_metadata)?;
io::copy(&mut reader, &mut writer)
}
2018-05-15 13:25:09 +00:00
2018-05-16 08:17:06 +00:00
#[cfg(any(target_os = "linux", target_os = "android"))]
2018-05-15 13:25:09 +00:00
pub fn copy(from: &Path, to: &Path) -> io::Result<u64> {
2019-02-10 19:23:21 +00:00
use crate::cmp;
use crate::sync::atomic::{AtomicBool, Ordering};
// Kernel prior to 4.5 don't have copy_file_range
2018-08-19 13:30:23 +00:00
// We store the availability in a global to avoid unnecessary syscalls
static HAS_COPY_FILE_RANGE: AtomicBool = AtomicBool::new(true);
2018-05-15 13:25:09 +00:00
unsafe fn copy_file_range(
fd_in: libc::c_int,
off_in: *mut libc::loff_t,
fd_out: libc::c_int,
off_out: *mut libc::loff_t,
len: libc::size_t,
flags: libc::c_uint,
) -> libc::c_long {
libc::syscall(
libc::SYS_copy_file_range,
fd_in,
off_in,
fd_out,
off_out,
len,
flags,
)
}
let (mut reader, reader_metadata) = open_from(from)?;
let len = reader_metadata.len();
let (mut writer, _) = open_to_and_set_permissions(to, reader_metadata)?;
2018-05-16 08:17:06 +00:00
let has_copy_file_range = HAS_COPY_FILE_RANGE.load(Ordering::Relaxed);
2018-05-15 13:25:09 +00:00
let mut written = 0u64;
while written < len {
let copy_result = if has_copy_file_range {
let bytes_to_copy = cmp::min(len - written, usize::max_value() as u64) as usize;
let copy_result = unsafe {
// We actually don't have to adjust the offsets,
// because copy_file_range adjusts the file offset automatically
cvt(copy_file_range(
reader.as_raw_fd(),
ptr::null_mut(),
writer.as_raw_fd(),
ptr::null_mut(),
bytes_to_copy,
0,
))
};
if let Err(ref copy_err) = copy_result {
match copy_err.raw_os_error() {
Some(libc::ENOSYS) | Some(libc::EPERM) => {
HAS_COPY_FILE_RANGE.store(false, Ordering::Relaxed);
}
_ => {}
}
}
copy_result
} else {
Err(io::Error::from_raw_os_error(libc::ENOSYS))
2018-05-15 13:25:09 +00:00
};
match copy_result {
Ok(ret) => written += ret as u64,
Err(err) => {
match err.raw_os_error() {
Some(os_err)
if os_err == libc::ENOSYS
|| os_err == libc::EXDEV
|| os_err == libc::EINVAL
|| os_err == libc::EPERM =>
{
// Try fallback io::copy if either:
// - Kernel version is < 4.5 (ENOSYS)
// - Files are mounted on different fs (EXDEV)
// - copy_file_range is disallowed, for example by seccomp (EPERM)
// - copy_file_range cannot be used with pipes or device nodes (EINVAL)
assert_eq!(written, 0);
return io::copy(&mut reader, &mut writer);
}
2018-05-15 13:25:09 +00:00
_ => return Err(err),
}
}
}
}
Ok(written)
}
#[cfg(any(target_os = "macos", target_os = "ios"))]
pub fn copy(from: &Path, to: &Path) -> io::Result<u64> {
use crate::sync::atomic::{AtomicBool, Ordering};
const COPYFILE_ACL: u32 = 1 << 0;
const COPYFILE_STAT: u32 = 1 << 1;
const COPYFILE_XATTR: u32 = 1 << 2;
const COPYFILE_DATA: u32 = 1 << 3;
const COPYFILE_SECURITY: u32 = COPYFILE_STAT | COPYFILE_ACL;
const COPYFILE_METADATA: u32 = COPYFILE_SECURITY | COPYFILE_XATTR;
const COPYFILE_ALL: u32 = COPYFILE_METADATA | COPYFILE_DATA;
const COPYFILE_STATE_COPIED: u32 = 8;
#[allow(non_camel_case_types)]
type copyfile_state_t = *mut libc::c_void;
#[allow(non_camel_case_types)]
type copyfile_flags_t = u32;
extern "C" {
fn fcopyfile(
from: libc::c_int,
to: libc::c_int,
state: copyfile_state_t,
flags: copyfile_flags_t,
) -> libc::c_int;
fn copyfile_state_alloc() -> copyfile_state_t;
fn copyfile_state_free(state: copyfile_state_t) -> libc::c_int;
fn copyfile_state_get(
state: copyfile_state_t,
flag: u32,
dst: *mut libc::c_void,
) -> libc::c_int;
}
struct FreeOnDrop(copyfile_state_t);
impl Drop for FreeOnDrop {
fn drop(&mut self) {
// The code below ensures that `FreeOnDrop` is never a null pointer
unsafe {
// `copyfile_state_free` returns -1 if the `to` or `from` files
// cannot be closed. However, this is not considerd this an
// error.
copyfile_state_free(self.0);
}
}
}
// MacOS prior to 10.12 don't support `fclonefileat`
// We store the availability in a global to avoid unnecessary syscalls
static HAS_FCLONEFILEAT: AtomicBool = AtomicBool::new(true);
syscall! {
fn fclonefileat(
srcfd: libc::c_int,
dst_dirfd: libc::c_int,
dst: *const libc::c_char,
flags: libc::c_int
) -> libc::c_int
}
let (reader, reader_metadata) = open_from(from)?;
// Opportunistically attempt to create a copy-on-write clone of `from`
// using `fclonefileat`.
if HAS_FCLONEFILEAT.load(Ordering::Relaxed) {
let to = cstr(to)?;
let clonefile_result = cvt(unsafe {
fclonefileat(
reader.as_raw_fd(),
libc::AT_FDCWD,
to.as_ptr(),
0,
)
});
match clonefile_result {
Ok(_) => return Ok(reader_metadata.len()),
Err(err) => match err.raw_os_error() {
// `fclonefileat` will fail on non-APFS volumes, if the
// destination already exists, or if the source and destination
// are on different devices. In all these cases `fcopyfile`
// should succeed.
Some(libc::ENOTSUP) | Some(libc::EEXIST) | Some(libc::EXDEV) => (),
Some(libc::ENOSYS) => HAS_FCLONEFILEAT.store(false, Ordering::Relaxed),
_ => return Err(err),
}
}
}
// Fall back to using `fcopyfile` if `fclonefileat` does not succeed.
let (writer, writer_metadata) = open_to_and_set_permissions(to, reader_metadata)?;
// We ensure that `FreeOnDrop` never contains a null pointer so it is
// always safe to call `copyfile_state_free`
let state = unsafe {
let state = copyfile_state_alloc();
if state.is_null() {
return Err(crate::io::Error::last_os_error());
}
FreeOnDrop(state)
};
let flags = if writer_metadata.is_file() {
COPYFILE_ALL
} else {
COPYFILE_DATA
};
cvt(unsafe {
fcopyfile(
reader.as_raw_fd(),
writer.as_raw_fd(),
state.0,
flags,
)
})?;
let mut bytes_copied: libc::off_t = 0;
cvt(unsafe {
copyfile_state_get(
state.0,
COPYFILE_STATE_COPIED,
&mut bytes_copied as *mut libc::off_t as *mut libc::c_void,
)
})?;
Ok(bytes_copied as u64)
}