Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Ability to construct virtual `Dir`s to mount files and subdirectories into

Aperta
#352 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
rust
Ambito
operating-systems, security

Direzione di ricerca

Inizia leggendo le API esistenti per la costruzione di Dir e i metodi insert di Pool, quindi confronta il modo in cui i percorsi vengono aperti e rappresentati. Determina se i file virtuali e le sottodirectory possono essere montati senza aprirli, preservando le restrizioni sulla capacità ricorsiva. Done dovrebbe includere un design multipiattaforma definito, compreso il caso d’uso proposto della radice di un’unità Windows, con comportamento e test documentati.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Specifically with the option for those files/dirs to just be paths that don’t need to be opened when mounted. Note: When I say “mount” here this would only be internal to the Dir struct and not actual mounts on the underling filesystem. Similar to Pool’s insert methods.

Would particularly be interesting to create a root Dir which would just be / on Unix but on Windows a folder exposing all drive letters as subfolders. I understand that this specific use case may be controversial, as it seems to go against the spirit of this crate. But I believe the opposite to be true: The great thing about this API is that it doesn’t just have one or two layers (as more basic security systems), but arbitrarily many as each Dir recursively can be used to create narrower views. So I don’t think one global directory as the base to craft more specialised capabilities would inherently be a bad idea.

Based originally on thinking in https://github.com/bytecodealliance/wasmtime/issues/8552 to solve the problem of Windows (unlike Unix) not having a single root folder but essentially one for each volume, which makes cap-std difficult to use in some contexts.

I apologise should what I propose already be possible, in a quick look into the docs I haven’t figured out a way to do this.

Lingua principale
Rust
Stelle
821
Fork
59
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di bytecodealliance/cap-std

Tutte le issue di bytecodealliance/cap-std

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.