Skip to content

Let the simple example be mounted idmapped #750

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
cberner merged 2 commits into from
Aug 8, 2026
Merged

Let the simple example be mounted idmapped #750

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
73a60b0
Let the simple example be mounted idmapped
claude Aug 7, 2026
5eab41e
Give a rename an owner only where it creates an inode
claude Aug 7, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,8 @@
`InitFlags::FUSE_ALLOW_IDMAP` is always given ids and can unwrap
* **Breaking:** `mknod()`, `mkdir()`, `symlink()`, `create()` and `tmpfile()` take an `Owner`
argument, which is who the inode they create belongs to, and `rename()` takes an
`Option<Owner>` for the inode a `RENAME_WHITEOUT` leaves behind. Those are exactly the requests the
`Option<Owner>`, which is `Some` for the inode a `RENAME_WHITEOUT` leaves behind and `None`
for any other rename, those creating nothing to own. Those are exactly the requests the
kernel sends ids for, and on an idmapped mount the owner is the caller's ids mapped through
the mount's idmapping rather than the ids themselves, so reading it off the request would
have been wrong
Expand Down
Loading
Loading