| Age | Commit message (Collapse) | Author | Lines |
|---|
|
PR 130999 added the file_lock feature, but doesn't included OpenBSD in the supported targets (Tier 3 platform), leading to a compilation error ("try_lock() not supported").
(cherry picked from commit 8792010768cff60d202b3608e6918be3199aeae2)
|
|
|
|
|
|
|
|
It uses the file metadata on Unix with a fallback for files incorrectly
reported as zero-sized. It uses `GetFileSizeEx` on Windows.
This reduces the number of syscalls needed for determining the file size
of an open file from 3 to 1.
|
|
Add From<TryLockError> for io::Error
Adds a `From` impl to make error propagation easier, as discussed in the tracking issue
`TryLockError` is unstable under the "file_lock" feature. The related tracking issue is https://github.com/rust-lang/rust/issues/130994
This PR also cleanups the Windows implementation of `try_lock()` and `try_lock_shared()` as [discussed here](https://github.com/rust-lang/rust/pull/140718#discussion_r2076678485)
|
|
try_lock() and try_lock_shared() do not need to handle these per the discussion in https://github.com/rust-lang/rust/pull/140718#discussion_r2076678485
|
|
|
|
Change signature of File::try_lock and File::try_lock_shared
These methods now return Result<(), TryLockError> instead of Result<bool, Error> to make their use less errorprone
These methods are unstable under the "file_lock" feature. The related tracking issue is https://github.com/rust-lang/rust/pull/130999 and this PR changes the signatures as discussed by libs-api: https://github.com/rust-lang/rust/issues/130994#issuecomment-2770838848
|
|
These methods now return Result<(), TryLockError> instead of
Result<bool, Error> to make their use less errorprone
|
|
in core/alloc/std only for now, and ignoring test files
Co-authored-by: Pavel Grigorenko <GrigorenkoPV@ya.ru>
|
|
Impl new API `std::os::unix::fs::mkfifo` under feature `unix_fifo`
Tracking issue #139324
|
|
Tracking issue #139324
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
|
|
|
|
cfi: Remove #[no_sanitize(cfi)] for extern weak functions
Previously (https://github.com/rust-lang/rust/pull/115200, https://github.com/rust-lang/rust/pull/138002), we added `#[no_sanitize(cfi)]` to all code paths that call to a weakly linked function.
In https://github.com/rust-lang/rust/pull/138349 we fixed the root cause for this issue, which means we can now remove the corresponding attributes.
r? `@rcvalle`
|
|
Use `with_native_path` for Windows
Ideally, each platform should use their own native path type internally. This will, for example, allow passing a UTF-16 string directly to `std::fs::File::open` and therefore avoid the need for allocating a new null-terminated wide string. However, doing that for every function and platform all at once makes for a large PR that is way too prone to breaking. So this just does some of the Windows parts.
As with the previous Unix PR (#138832) this is intended to be merely a refactoring so I've avoided anything that may require more substantial changes.
|
|
Update windows-bindgen to 0.61.0
This updates the automatically generate Windows API bindings. Not much changed this time:
- There's now `Default` implementations for many types, which is convenient. It does however conflict with one place where we implemented a non-zeroed default (to set the length field). But that's no big problem.
- The `--no-core` flag has been renamed to `--no-deps` to more accurately reflect its meaning (i.e. generate all necessary code without requiring additional dependencies).
- The `--link` flag allows us to set the location of the `link!` macro. Currently we use our workspace's `windows_targets` crate but we could move it into library/std using `--link`. However, this would need to be co-ordinated with the `backtrace` crate (which is a separate crate but included in std using `#[path]`). So I've left that for another time.
|
|
Also add a WCStr type
|
|
Previously (https://github.com/rust-lang/rust/pull/115200,
https://github.com/rust-lang/rust/pull/138002), we
added `#[no_sanitize(cfi)]` to all code paths that call to a weakly
linked function.
In https://github.com/rust-lang/rust/pull/138349 we fixed the root cause
for this issue, which means we can now remove the corresponding
attributes.
|
|
Move `fd` into `std::sys`
Move platform definitions of `fd` into `std::sys`, as part of https://github.com/rust-lang/rust/issues/117276.
Unlike other modules directly under `std::sys`, this is only available on some platforms and I have not provided a fallback abstraction for unsupported platforms. That is similar to how `std::os::fd` is gated to only supported platforms.
Also, fix the `unsafe_op_in_unsafe_fn` lint, which was allowed for the Unix fd impl. Since macro expansions from `std::sys::pal::unix::weak` trigger this lint, fix it there too.
cc `@joboet,` `@ChrisDenton`
try-job: x86_64-gnu-aux
|
|
|
|
|
|
Fix UWP reparse point check
Fixes #138921
|
|
Start using `with_native_path` in `std::sys::fs`
Ideally, each platform should use their own native path type internally. This will, for example, allow passing a `CStr` directly to `std::fs::File::open` and therefore avoid the need for allocating a new null-terminated C string.
However, doing that for every function and platform all at once makes for a large PR that is way too prone to breaking. So this PR does some minimal refactoring which should help progress towards that goal. The changes are Unix-only and even then I avoided functions that require more changes so that this PR is just moving things around.
r? joboet
|
|
|
|
Change the syntax to include parameter names and a trailing semicolon.
Motivation:
- Mirror the `syscall!` macro.
- Allow rustfmt to format it (when wrapped in parentheses).
- For better documentation (having the parameter names available in
the source code is a bit nicer).
- Allow future improvements to this macro where we can sometimes use the
symbol directly when it's statically known to be available.
|
|
|
|
Implement some basics in UEFI fs
- Just getting some basics out of the way while waiting for #138236 to be merged.
- Adds `fs::canonicalize`. Should be same as absolute in case of UEFI since there is no symlink support and absolute path is guaranteed to be uniqe according to spec.
- Make `fs::lstat` same as `fs::stat`. Should be same since UEFI does not have symlink support.
- Implement `OptionOptions`.
cc ````@nicholasbishop```` ````@dvdhrm````
|
|
UEFI does not have specific modes for create_new, truncate and append.
So those need to to be simulated after opening the file.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
- UEFI does not have symlinks. So lstat and stat should behave the same.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
- Should be same as absolute in UEFI since there are no symlinks.
- Also each absolute path representation should be unique according to
the UEFI specification.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
Fix `FileType` `PartialEq` implementation on Windows
Fixes #138668
On Windows the [`FileType`](https://doc.rust-lang.org/stable/std/fs/struct.FileType.html) struct was deriving `PartialEq` which in turn means it was doing a bit-for-bit comparison on the file attributes and reparse point. This is wrong because `attributes` may contain many things unrelated to file type.
`FileType` on Windows allows for four possible combinations (see also [`FileTypeExt`](https://doc.rust-lang.org/stable/std/os/windows/fs/trait.FileTypeExt.html)): `file`, `dir`, `symlink_file` and `symlink_dir`. So the new implementation makes sure both symlink and directory information match (and only those things).
This could be considered just a bug fix but it is a behaviour change so someone from libs-api might want to FCP this (or might not)...
|
|
std: uefi: fs: Implement mkdir
- Since there is no direct mkdir in UEFI, first check if a file/dir with same path exists and then create the directory.
cc `@dvdhrm` `@nicholasbishop`
|
|
Rollup of 7 pull requests
Successful merges:
- #136320 (exit: document interaction with C)
- #138080 (Leave a breadcrumb towards bootstrap config documentation in `bootstrap.toml`)
- #138301 (Implement `read_buf` for Hermit)
- #138569 (rustdoc-json: Add tests for `#[repr(...)]`)
- #138635 (Extract `for_each_immediate_subpat` from THIR pattern visitors)
- #138642 (Unvacation myself)
- #138644 (Add `#[cfg(test)]` for Transition in dfa in `rustc_transmute`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
- Since there is no direct mkdir in UEFI, first check if a file/dir with
same path exists and then create the directory.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
Implement `read_buf` for Hermit
Following https://github.com/hermit-os/kernel/pull/1606, it is now safe to implement `Read::read_buf` for file descriptors on Hermit.
cc ```@mkroening```
|
|
uefi: fs: Implement exists
Also adds the initial file abstractions.
The file opening algorithm is inspired from UEFI shell. It starts by classifying if the Path is Shell mapping, text representation of device path protocol, or a relative path and converts into an absolute text representation of device path protocol.
After that, it queries all handles supporting
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and opens the volume that matches the device path protocol prefix (similar to Windows drive). After that, it opens the file in the volume using the remaining pat.
It also introduces OwnedDevicePath and BorrowedDevicePath abstractions to allow working with the base UEFI and Shell device paths efficiently.
DevicePath in UEFI behaves like an a group of nodes laied out in the memory contiguously and thus can be modeled using iterators.
This is an effort to break the original PR (https://github.com/rust-lang/rust/pull/129700) into much smaller chunks for faster upstreaming.
|
|
Also adds the initial file abstractions.
The file opening algorithm is inspired from UEFI shell. It starts by
classifying if the Path is Shell mapping, text representation of device
path protocol, or a relative path and converts into an absolute text
representation of device path protocol.
After that, it queries all handles supporting
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and opens the volume that matches the
device path protocol prefix (similar to Windows drive). After that, it
opens the file in the volume using the remaining pat.
It also introduces OwnedDevicePath and BorrowedDevicePath abstractions
to allow working with the base UEFI and Shell device paths efficiently.
DevicePath in UEFI behaves like an a group of nodes laied out in the
memory contiguously and thus can be modeled using iterators.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
|
|
Add std support to cygwin target
|
|
uefi: fs: Implement FileType, FilePermissions and FileAttr
- In UEFI, both FileType and FilePermissions are represented by the attr bitfield.
- Using simple bools here since both are represented by a single bit.
- Add `FILE_PERMISSION` mask for constructing attribute while change permissions.
cc ````@nicholasbishop````
|
|
Disable CFI for weakly linked syscalls
Currently, when enabling CFI via -Zsanitizer=cfi and executing e.g. std::sys::random::getrandom, we can observe a CFI violation. This is the case for all consumers of the std::sys::pal::weak::syscall macro, as it is defining weak functions which don't show up in LLVM IR metadata. CFI fails for all these functions.
Similar to other such cases in
https://github.com/rust-lang/rust/issues/115199, this change stops emitting the CFI typecheck for consumers of the macro via the `#[no_sanitize(cfi)]` attribute.
r? ``````@rcvalle``````
|
|
|
|
Signed-off-by: Ookiineko <chiisaineko@protonmail.com>
|
|
|
|
Currently, when enabling CFI via -Zsanitizer=cfi and executing e.g.
std::sys::random::getrandom, we can observe a CFI violation. This is
the case for all consumers of the std::sys::pal::weak::weak macro,
as it is defining weak functions which don't show up in LLVM IR
metadata. CFI fails for all these functions.
Similar to other such cases in
https://github.com/rust-lang/rust/issues/115199, this change stops
emitting the CFI typecheck for consumers of the macro via the
\#[no_sanitize(cfi)] attribute.
|
|
- Just the permission and file type.
- FileTimes will need some new conversion functions and thus will come
with a future PR. Trying to keep things simple here.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
- Similar to FilePermissions, using bool to represent the bitfield.
- FileType cannot be changed, so no need to worry about converting back
to attribute.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
|
- UEFI file permissions are indicated using a u64 bitfield used for
readonly/filetype, etc.
- Using normal bool with to and from attribute conversions to
FilePermission from overriding some other bitfields.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
|
