Age | Commit message (Collapse) | Author |
|
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
|
|
It returns the mount flags on the BSDs. On Linux, it returns a slightly
different set of flags.
|
|
|
|
And fstatfs64 instead of fstatfs.
|
|
https://github.com/rust-lang/libc/pull/2963
|
|
|
|
See https://github.com/nix-rust/nix/pull/1744 for more details
|
|
New implementation performs no allocations after all the necessary
structures are created, removes potentially unsound code that
was used by the old version (see below) and adds a bit more
documentation about bugs in how timeout is actually handled
```
let timeout = if let Some(mut t) = timeout {
t.as_mut() as *mut libc::timespec
} else {
ptr::null_mut()
};
```
|
|
We'll be using that to reinitialize buffers later
|
|
This is already an unsafe function, dealing with pointers directly
does not make it much more unsafe but simplifies lifetimes later on
and similar to a previous commit allows to alocate a single buffer
to store all the control messages
|
|
CMSG_FIRSTHDR/CMSG_NEXTHDR operate in terms of pointers contained
inside msghdr structure, vector capacity doesn't matter for them.
This would change external behavior of recvmsg/recvmmsg in a sense
that buffer passed to store controll messages won't have it's length
updated but intended way to receive control messages is with cmsgs
iterator on `RecvMsg` which would still work.
This change is required to allow using a single vector to store
control messages from multiple packets
|
|
|
|
1842: add eaccess on freebsd, dragonfly and linux r=rtzoeller a=SteveLauC
#### man pages
* [FreeBSD](https://www.freebsd.org/cgi/man.cgi?query=eaccess&sektion=2&n=1)
* [DragonFly](https://man.dragonflybsd.org/?command=access§ion=2)
* [Linux](https://man7.org/linux/man-pages/man3/euidaccess.3.html)
#### difference between `eaccess` and `access/faccessat`
IMHO, `eaccess` uses effective identifiers to perform the permission check while `access/faccessat` use real IDs.
Fixes #1373
Co-authored-by: Steve Lau <stevelauc@outlook.com>
|
|
|
|
|
|
|
|
|
|
1833: add syncfs on linux r=rtzoeller a=SteveLauC
Fixes #1818
Change has not been added to `CHANGELOG.md`, will add it when #1831 is merged, or there will be a merge conflict
Co-authored-by: Steve Lau <stevelauc@outlook.com>
|
|
Clippy is now smarter about detecting unnecessary casts and
useless conversions, which means we need to be more explicit
about when the conversions are needed for a subset of platforms.
Required changes found by repeatedly running the following command
against a list of the supported platforms.
`xargs -t -I {} sh -c "cargo clippy -Zbuild-std --target {} --all-targets -- -D warnings || exit 255"`
I removed the casts it complained about, and then restored them
with an `#[allow]` if a later target needed the cast.
|
|
|
|
|
|
Namespace filesystem magic is missing from FsType constants.
|
|
1825: Add a `sched_getcpu` wrapper r=rtzoeller a=jonas-schievink
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
|
|
|
|
|
|
|
|
1808: expose memfd on freebsd r=asomers a=i509VCB
Resolves #1775
Co-authored-by: i509VCB <git@i509.me>
|
|
1815: Handle unacceptable name gracefully in {User,Group}::from_name r=asomers a=magicant
Calling `unwrap` on the result of `CString::new` may cause the current thread to panic, which is a bit surprising undocumented behavior. It would be more reasonable to treat the erroneous name as a non-existing user or group.
Co-authored-by: WATANABE Yuki <magicant@wonderwand.net>
|
|
|
|
|
|
Calling `unwrap` on the result of `CString::new` may cause the current
thread to panic, which is a bit surprising undocumented behavior. It
would be more reasonable to treat the erroneous name as a non-existing
user or group.
|
|
|
|
|
|
1805: Add `line` field to `Termios` struct r=rtzoeller a=tertsdiepraam
Fixes https://github.com/nix-rust/nix/issues/1802
I have to admit I'm not really sure how to test this properly, so if that's necessary I require some help :)
Co-authored-by: Terts Diepraam <terts.diepraam@gmail.com>
|
|
|
|
1806: Remove MSRV-related workaround for doc aliases r=asomers a=rtzoeller
Remove the MSRV-related workaround added by #1693, since we now can use doc aliases in all supported versions of Rust.
Closes #1674.
Co-authored-by: Ryan Zoeller <rtzoeller@rtzoeller.com>
|
|
|
|
|
|
And fix some documentation lints warned about by the newer rustdoc.
|
|
1782: feat #1733: add F_GET_SEALS and F_ADD_SEALS on FreeBSD r=rtzoeller a=SteveLauC
Closes #1733
Co-authored-by: SteveLauC <stevelauc@outlook.com>
|
|
|
|
1776: Add support for the IP_SENDSRCADDR control message r=rtzoeller a=matttpt
This control message is available on FreeBSD, NetBSD, and OpenBSD. When used with `sendmsg`, it sets the IPv4 source address. This adds support through a new `ControlMessage::Ipv4SendSrcAddr` variant that complements `ControlMessageOwned::Ipv4RecvDstAddr`.
A few notes:
* `IP_SENDSRCADDR` is actually just an alias for `IP_RECVDSTADDR` (though the code doesn't depend on this).
* On NetBSD, `IP_PKTINFO` can be used to accomplish the same thing and is already supported by nix. On FreeBSD and OpenBSD, though, `IP_SENDSRCADDR` is the only method I'm aware of.
* The accompanying test binds a UDP socket to all local interfaces (0.0.0.0). If this is not acceptable, please let me know; however, FreeBSD requires this to use `IP_SENDSRCADDR`.
I'll add a change-log entry once I see the PR number.
Thanks!
Co-authored-by: Matthew Ingwersen <matttpt@gmail.com>
|
|
1785: Remove deprecated items r=asomers a=SteveLauC
#### What this pr does
1. Convert `assert!(x == y)` to `assert_eq!(x, y)`
2. Convert `assert!(x != y)` to `assert_ne!(x, y)`
3. Add `.unwrap()` to unused `Result/Option` (in code comments)
4. Convert `std::ixx::MAX` to `ixx::MAX`
5. Convert `Box<Trait>` to `Box<dyn Trait>`
Co-authored-by: SteveLauC <stevelauc@outlook.com>
Co-authored-by: SteveLau <stevelauc@outlook.com>
|
|
|
|
|
|
1790: minor terminology fix in User docs r=asomers a=oconnor663
Passwords are hashed, not encrypted.
Co-authored-by: Jack O'Connor <oconnor663@gmail.com>
|
|
Passwords are hashed, not encrypted.
|
|
|
|
|
|
|