Support symlink follow control#2
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 18cb069862
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b3a138d55c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Lines 63 to 64 in 204c6e4
With this change, open(..., follow_symlink=true) and helpers like write_file can write through a symlink, but the public create(path) helper still delegates to @raw.create(path), whose default lookup flags are no-follow. In the common case where callers use create("link-to-file") to truncate/write an existing symlinked file, it still raises on the symlink instead of following the same default behavior as open; route this through open(path, mode=WriteOnly, create_mode=CreateOrTruncate) or add/pass the new flag.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Why
miniio path operations always used WASI's default no-follow lookup behavior, which made symlinked files and directories unusable through the public filesystem helpers. The examples also referenced older dependency versions that pulled an outdated async package.
What changed
follow_symlink? : Bool = trueoptions toopenandreaddir, matching the boolean style used bymoonbitlang/async/fs.LookupFlags.0.2.1and refreshes example dependency versions.Why this is minimal
The root API exposes a small boolean instead of leaking WASI-specific flags. The raw
LookupFlagssupport is limited to the internal/raw layer where the WASI bit is needed.