From cf7c0ffef791c6d9786a08449f697347ec3ae180 Mon Sep 17 00:00:00 2001 From: David Carlier Date: Sun, 6 Sep 2026 22:06:44 +0100 Subject: [PATCH] std: fix set_permissions_nofollow on espidf and horizon read(true) was chained onto custom_flags(O_NOFOLLOW) inside a cfg block that excludes those two targets, so their OpenOptions had no access mode set and open() returned EINVAL before any chmod happened. Neither target has an fchmodat arm either, so set_permissions_nofollow could never succeed there. --- library/std/src/sys/fs/unix.rs | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/library/std/src/sys/fs/unix.rs b/library/std/src/sys/fs/unix.rs index 5d5eae5b26a19..613397e6903c1 100644 --- a/library/std/src/sys/fs/unix.rs +++ b/library/std/src/sys/fs/unix.rs @@ -1911,6 +1911,7 @@ pub fn set_perm_nofollow(p: &CStr, perm: FilePermissions) -> io::Result<()> { use crate::fs::{OpenOptions, Permissions}; let mut options = OpenOptions::new(); + options.read(true); // ESP-IDF and Horizon do not support O_NOFOLLOW, so we skip setting it. // Their filesystems do not have symbolic links, so no special handling is required. @@ -1920,7 +1921,7 @@ pub fn set_perm_nofollow(p: &CStr, perm: FilePermissions) -> io::Result<()> { use crate::os::unix::fs::OpenOptionsExt; #[cfg(target_os = "wasi")] use crate::os::wasi::fs::OpenOptionsExt; - options.read(true).custom_flags(libc::O_NOFOLLOW); + options.custom_flags(libc::O_NOFOLLOW); } // SAFETY: Since this function is called with `with_native_path`