Skip to content
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.

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

Already on GitHub? Sign in to your account

Rename with Different Name Than Request #555

Open
404Wolf opened this issue Jan 16, 2025 · 3 comments
Open

Rename with Different Name Than Request #555

404Wolf opened this issue Jan 16, 2025 · 3 comments

Comments

@404Wolf
Copy link

404Wolf commented Jan 16, 2025

I think that it would be helpful if the NodeRenamer Rename let you return an error code, AND the new name. Maybe I'm misunderstanding, but I don't see a good way as is to implement a rename function that looks at the request and chooses to rename to a different name instead of the requested name, without intentionally returning a nonzero code and manually doing the MvChild yourself (which isn't good because then the error is propagated).

I propose making line 612

errno, newName := mops.Rename(&fuse.Context{Caller: input.Caller, Cancel: cancel}, oldName, p2.ops, newName, input.Flags)

Where newName is a string pointer (that can be null), or something along these lines.

func (b *rawBridge) Rename(cancel <-chan struct{}, input *fuse.RenameIn, oldName string, newName string) fuse.Status {

Or, maybe there's a way to do this that I'm not aware of. Thanks for your consideration!

@hanwen
Copy link
Owner

hanwen commented Jan 16, 2025

how would the VFS get to know about your new name?

@404Wolf
Copy link
Author

404Wolf commented Jan 16, 2025

how would the VFS get to know about your new name?

This very well could be an xy question, but in the fuse fs I'm implementing I want to "autocorrect" renames for the user, so I was thinking that changing the resultant name in rename would be a natural place to do that. I'm implementing lookup and readdir, so I'd imagine that I would be responsible for knowing of the new name. Another, maybe more ergonomic way of doing it is perhaps by allowing Rename to return some special error number (50, or something), that tells the bridge Rename not to execute the rename/it's already been handled, but return a 0.

@hanwen
Copy link
Owner

hanwen commented Jan 18, 2025

the VFS lives in the kernel. FUSE can either respond 0 (kernel assumes the rename happened, and the inode is now live with the new name) or a non-zero error code (kernel assumes the rename failed, and things did not change).

You could return 0, and make a hardlink to the corrected name (in addition to the incorrect name), and remove the incorrect name asynchronously, using entry notify to update the kernel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants