-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
pinning + pathresolver: fix pinning/unpinning of sharded directories #3975
Conversation
* Change ResolveToCid to take a Resolver and a NameSystem instead of an ipfs Node. * Make the pin/unpin methods use a Unixfs path resolver. Closes: ipfs#3974 License: MIT Signed-off-by: Steven Allen <steven@stebalien.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
License: MIT Signed-off-by: Steven Allen <steven@stebalien.com>
We may want to hold this pending the discussion in #3910 (comment) (as it's possible to pin IPLD objects). |
Can't you path through IPLD objects? Also, whatever happened to |
You can path through ipld objects, that works fine. And shard nodes are very specific protobufs, so theres no ambiguity between a path in an ipld node and a path through a sharded node. The only issue happens when you want to address an intermediate shard element directly |
@@ -377,13 +378,18 @@ new pin and removing the old one. | |||
return | |||
} | |||
|
|||
fromc, err := core.ResolveToCid(req.Context(), n, from) | |||
r := &path.Resolver{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This construction is more and more frequent around, it might be good to store it in ipfs node struct or have helper for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the end of the day, I think a better solution would be to avoid this resolver dance altogether. The root of the issue comes from the fact that the path doesn't dictate how it should be interpreted: as an IPLD path through IPLD objects (where the segments are keys) or an IPFS path through potentially sharded IPFS directories (where the segments are directory entries). To work around this:
- It's up to commands to chose the initial resolver.
- Resolvers do some additional magic under the covers to detect if a node should be treated as an IPLD or IPFS object by looking at it's Cid (they really shouldn't be doing this).
The solution I've proposed is to use separate prefixes: /ipld/...
and /ipfs/...
(ipfs/notes#248). I believe this is how this was intended to work (when designed) anyways.
If we did this, we could pass around the protocol along with the Cid/relative path so that core.Resolve
and core.ResolveToCid
could pick the right resolver for the given protocol.
Node.
Closes: #3974
License: MIT
Signed-off-by: Steven Allen steven@stebalien.com