I just started messing with running the operating system in qemu and was trying to look for a simple, small piece of the project to attempt to update. I noticed while moving around the shell that the ‘mv’ command was throwing a ‘not implemented’ exception, and thought I might get around to implementing that at least on the redoxfs side. I think this would be initially more just an attempt to see if I could get it to work, than something that would result in a pull request, but the hope is to get to a contributing level in time.
My rust knowledge is about as close to non-existent past the syntax, but I’ve been jumping around the code base to figure out what this might entail, and I just wanted to see what the TODO would look like for this task.
Stage 1: Add new system call, handle unimplemented exception based on return codes from schemes
Steps
- There’s no SYS_RENAME syscall yet. An integer would need to be set in the syscall const definitiions
- In kernel/syscall/mod.rs SYS_RENAME would have to point to a ‘rename’ function in syscall/fs.rs
- The rename function in fs.rs would then call the rename function in the scheme based on the url that it was fed.
- A ‘rename’ function would then need to be added to all schemes, and would have to return an error by default. (I’m assuming that panicking in this case is a really bad idea)
- The rename/move function in the redox stdli would then need to call the new syscall and based on that error code throw the unimplemented instruction. This would leave way for implementing the actual move call in the redoxfs scheme.
End result
‘mv’ still throws an exception, but the attempt to rename actually passes through the kernel and to the schemes that it’s attempting to access.
Stage 1: Add new system call, handle unimplemented exception based on return codes from schemes
Steps
- There’s no SYS_RENAME syscall yet. An integer would need to be set in the syscall const definitiions
- In kernel/syscall/mod.rs SYS_RENAME would have to point to a ‘rename’ function in syscall/fs.rs
- The rename function in fs.rs would then call the rename function in the scheme based on the url that it was fed.
- A ‘rename’ function would then need to be added to all schemes, and would have to return an error by default. (I’m assuming that panicking in this case is a really bad idea)
- The rename/move function in the redox stdli would then need to call the new syscall and based on that error code throw the unimplemented instruction. This would leave way for implementing the actual move call in the redoxfs scheme.
End result
‘mv’ still throws an exception, but the attempt to rename actually passes through the kernel and to the schemes that it’s attempting to access.
Stage 2: Implement rename in redoxfs scheme
Sorry, this is much less fleshed out.
Steps
- Create a rename function in redoxfs/mount/redox/scheme.rs. Have it return an errror result. (commit 1
- Change function to rename IFF the parent block hasn’t changed. Do this using the find_node function, changing the ‘name’ bytes and re-writing the node at the same block. (commit 2)
- Change the function to do something like this. (commit 3)
- node renaming logic from above
- Get the parent node and soon-to-be-parent node
- Change the list of children (Is this using the extents array if it’s a directory?) for the soon-to-be-parent node to reference the node block of the file. Write the new parent to disk. (I guess there’s two references, but if the system explodes you don’t lose the file.)
- Change the list of children on the old parent to remove the reference to the moved node.
End result
‘mv’ can rename a file in place or change the full file path. (within the same scheme)
Question
Am I headed in the right direction? I’d imagine this would keep me busy for quite some time, but is there anything that’s going to trip me up here way more than I expect?