Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Treat the WASM/WASI build target as cfg(unix) so filesystem tools need no per-tool mode-bit patches

Abierto
  • ¿Algo no está bien?
#271 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
rust, wasm
Área
build-system, operating-systems

Línea de trabajo

Comienza con uutils/coreutils' src/uucore/src/lib/features/fs.rs y compara los parches de WASI referenciados en registry/native/patches con los puntos de entrada which.rs y builtins. Investiga las alternativas target-spec, build-std y preview2 descritas aquí; se considera terminado cuando se haya seleccionado y documentado una dirección junto con sus consecuencias para la compatibilidad y el mantenimiento.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

We build coreutils (ls, stat, chmod, …) for wasm32-wasip1. Because that
target is not cfg(unix), every crate's #[cfg(unix)] filesystem code —
the code that reads real st_mode permission bits — is compiled out, and the
#[cfg(not(unix))] fallback (which fabricates permissions from a single
readonly boolean) is compiled in. To get native-Linux-accurate output we've
had to hand-patch each tool to bypass that fallback and fetch mode bits from the
sidecar via a host_fs.path_mode import (landed in #268 / #269).

This issue tracks the larger question: should we make the WASM build target
present as cfg(unix) (a Linux-like target) so these tools "just work" with no
per-tool patches, instead of maintaining a growing pile of #[cfg(target_os = "wasi")] shims?

Why a non-Linux target breaks filesystem tools

uucore has two implementations of display_permissions, cfg-gated:

#[cfg(unix)]                       // reads REAL bits
pub fn display_permissions(md, ...) -> String {
    display_permissions_unix(md.mode() as mode_t, ...)   // st_mode
}

#[cfg(not(unix))]                  // WASI lands HERE — fabricates
pub fn display_permissions(md, display_file_type) -> String {
    let write = if md.permissions().readonly() { '-' } else { 'w' };
    format!("{file_type}r{write}xr{write}xr{write}x")     // r & x HARDCODED on
}

Upstream root cause (uutils/coreutils, uucore 0.5.0):
https://github.com/uutils/coreutils/blob/main/src/uucore/src/lib/features/fs.rs

Consequences of being cfg(not(unix)):

  • md.mode() isn't even callable — std::os::unix::fs::MetadataExt doesn't
    exist in the WASI std.
  • Rust's own std::os::wasi::fs::MetadataExt deliberately exposes
    dev/ino/nlink/size/atim/… but no mode(), because WASI preview1's
    filestat struct has no mode field. So the bits are absent at the std layer
    regardless of cfg.
  • Net effect: ls -l printed -rwxrwxrwx (or -r-xr-xr-x if readonly) for
    every file — a uniform string derived from one boolean.

Note this is degradation, not deliberate stripping: the tools have "WASI
support," it's just a lossy fallback nobody wired to a host that has the bits.

Evidence: the per-tool workarounds this forces (all at 8145b07)

Each of these exists only because the target isn't cfg(unix):

Every new fs-touching Rust tool we add will need another such patch.

Options

A. Force cfg(unix) on the current target (cheap, does NOT work)

Passing --cfg unix via RUSTFLAGS flips the cfg on our crates, but the
#[cfg(unix)] path does use std::os::unix::fs::MetadataExt, which the
precompiled WASI std doesn't contain → unresolved import. And even if it
resolved, the WASI Metadata's underlying filestat has no st_mode to
return. Rejected.

B. Custom Linux-like target spec + -Z build-std (the real "treat it like native")

Define a target derived from wasm32-wasip1 with target-family = ["unix", …]
and recompile std/core so Rust's fs routes through the libc-backed unix fs
backend (calls libc stat(), reads st_mode). Then the wasi-libc mode patch
(0016) flows up into Rust automatically and all #[cfg(unix)] tool code works —
no per-tool patches. Blast radius, however, is large:

  • Nightly + build-std on every build; per-Rust-version maintenance of a bespoke
    target.
  • cfg(unix) flips the entire dep graph, not just perms — signals, process,
    users/groups (getpwuid), termios, mmap, net — much of which calls libc
    symbols WASI libc doesn't implement → link/ENOSYS breakage to chase.
  • The fs backend (target_os = "wasi") and MetadataExt (target_family = unix) are gated on different cfgs and don't cleanly compose; effectively a
    std fork.
C. Move the runtime to WASI preview2 / wasi:filesystem (the clean long-term fix)

preview2 carries richer metadata than preview1's filestat. Migrating (or
upstreaming a wasi MetadataExt::mode() backed by an extended filestat) would
let these tools read real bits natively and let us delete all the patches —
without pretending to be unix.

Ask / decision needed

Decide between: (B) invest in a Linux-like custom target + build-std so fs tools
need zero patches, vs. (C) target preview2, vs. (status quo) keep adding small
per-tool host_fs patches. Leaning C long-term; B is the "make it native" ask
but has broad blast radius. Capturing so the tradeoff is explicit before the
patch pile grows.

Related PRs: #268 (filesystem native-parity: wasi-libc + sidecar host_fs),
#269 (coreutils stat/chmod/ls real permission bits).

Lenguaje dominante
TypeScript
Estrellas
1k
Forks
54
Sin PR fusionados en 30 d

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rivet-dev/dynamic-apps

Todos los issues de rivet-dev/dynamic-apps

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.