Skip to content
This repository has been archived by the owner on Nov 18, 2022. It is now read-only.

Hard link name (and link refactoring) #42

Open
bbengfort opened this issue Feb 20, 2017 · 1 comment
Open

Hard link name (and link refactoring) #42

bbengfort opened this issue Feb 20, 2017 · 1 comment

Comments

@bbengfort
Copy link
Owner

bbengfort commented Feb 20, 2017

When a hard link is created the name isn't modified, meaning that there appear to be copies of the file and in order to remove the hard link, the referenced name must be removed, which is impossible to see.

@bbengfort bbengfort mentioned this issue Feb 21, 2017
3 tasks
@bbengfort bbengfort changed the title Hardlink name Hard link name (and link refactoring) Feb 21, 2017
@bbengfort
Copy link
Owner Author

So in order to fix this, I attempted to create a type Link that wrapped a Target (which was a pointer to an Entity object) such that all the FUSE methods passed through to the *Target except for the Path() and String() methods which referred to Link.Name.

This did not work.

First - I had to copy and paste every single method ... so it was verbose. Second, the Readdir() function uses GetNode(), which returns the *Target.Node and therefore the original name, so it didn't even fix the problem!

I was probably on the right track with this, but some better wrapping is necessary. We also have to update the filesystem to count links a bit better, and to manage the Attrs.Nlinks counter. We also have to update Readdir() to do better name checking.

Finally, I also want to make sure Symlinks are implemented as Link objects or have a shared link structure (even though they are just files). So some thought needs to be put into that.

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

No branches or pull requests

1 participant