You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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.
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.
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
Where newName is a string pointer (that can be null), or something along these lines.
go-fuse/fs/bridge.go
Line 607 in aa9c516
Or, maybe there's a way to do this that I'm not aware of. Thanks for your consideration!
The text was updated successfully, but these errors were encountered: