std: don't reference libc::O_NOFOLLOW on VxWorks in set_perm_nofollow

[physwkim]

set_permissions_nofollow was consolidated into sys/fs/unix.rs::set_perm_nofollow by #160170, which dropped the not(target_os = "vxworks") guard the previous sys/fs/mod.rs implementation carried. VxWorks' libc defines no O_NOFOLLOW (the platform's <sys/fcntlcom.h> stops at O_CLOEXEC, and rust-lang/libc correctly does not bind it for vxworks), so building std for x86_64-wrs-vxworks now fails:

error[E0425]: cannot find value `O_NOFOLLOW` in crate `libc`
    --> library/std/src/sys/fs/unix.rs:1916
     |
     |             options.read(true).custom_flags(libc::O_NOFOLLOW);
     |                                                    ^^^^^^^^^^ not found in `libc`

x86_64-wrs-vxworks is tier 3 and isn't built in CI, so this wasn't caught. set_perm_nofollow is the only O_NOFOLLOW reference compiled for VxWorks — the remove_dir_all "modern" path already lists vxworks in its fallback set, and the remaining occurrences are a doc example and comments.

Unlike ESP-IDF and Horizon (which skip O_NOFOLLOW because their filesystems have no symbolic links), VxWorks does have symlinks, so it can't just drop O_NOFOLLOW and follow the link silently. This returns ErrorKind::Unsupported, matching the existing Android stub.

Unsupported is the platform-correct result

Verified on-target against the shipped VxWorks 7 SDK (wrsdk-vxworks7-qemu-1.17.0, the QEMU BSP). VxWorks has no way to express a no-follow permission change:

• No O_NOFOLLOW. The only related flag is O_NOLINK ("open the symlink itself"), which is different semantics and not what the open + fchmod path wants.
• fchmodat is provided — by the UTILS_UNIX component in libunix, not core libc — and AT_SYMLINK_NOFOLLOW is defined as 0x100. But the shipped libunix.so rejects the flag with ENOTSUP:

0000000000009300 <fchmodat>:            ; (dirfd=edi, path=rsi, mode=edx, flag=ecx)
    cmpl   $0x100,-0x18(%rbp)           ; flag == AT_SYMLINK_NOFOLLOW ?
    jne    9340 <fchmodat+0x40>
    mov    $0x23,%edi                   ; errno = 0x23 (35 = ENOTSUP)
    call   errnoSet
    movl   $0xffffffff,-0x4(%rbp)       ; return -1
    ...
9340:                                   ; flag == 0
    call   taskSafe
    ...  atCatPath(dirfd, path)
    call   chmod                        ; plain chmod -> follows the symlink

So fchmodat(.., AT_SYMLINK_NOFOLLOW) returns -1/ENOTSUP, and flag == 0 degrades to chmod, which follows symlinks. A fchmodat-based implementation is not viable on this release — the platform's own fchmodat reports ENOTSUP for exactly this request, which is why Unsupported is correct rather than merely conservative. cc @biabbas @hax0kartik

Build verification

On 1.100.0-nightly (908501772 2026-08-30) + rust-src (stock libc 0.2.189):

• Before: cargo +nightly build -Zbuild-std=std,panic_abort --target x86_64-wrs-vxworks fails with the E0425 above (1 error).
• After this patch: the same command finishes successfully.

[rustbot]

r? @ChrisDenton

rustbot has assigned @ChrisDenton.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @ChrisDenton, libs
• @ChrisDenton, libs expanded to 13 candidates
• Random selection from 6 candidates

[ChrisDenton]

I can't verify on-target that VxWorks honors AT_SYMLINK_NOFOLLOW, so this only restores the build with conservative semantics.

It would be nice to verify this one way or another, even if we don't implement it just yet. cc @biabbas @hax0kartik

View changes since this review

[physwkim]

Tested on VxWorks 7 under QEMU: fchmodat(AT_FDCWD, path, mode, AT_SYMLINK_NOFOLLOW) returns -1/ENOTSUP, while flag = 0 falls through to chmod (which follows the symlink). So VxWorks does not honor AT_SYMLINK_NOFOLLOW, and Unsupported is the correct result.