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

Fix resolving links in sharded directories on gateway #5271

Merged
merged 5 commits into from
Jul 23, 2018
Merged

Conversation

magik6k
Copy link
Member

@magik6k magik6k commented Jul 21, 2018

Fixes #5270

License: MIT
Signed-off-by: Łukasz Magiera <[email protected]>
@magik6k magik6k requested a review from Kubuxu as a code owner July 21, 2018 12:59
@ghost ghost assigned magik6k Jul 21, 2018
@ghost ghost added the status/in-progress In progress label Jul 21, 2018
@magik6k magik6k changed the title Fix resolving links in sharded directories on gateway [WIP] Fix resolving links in sharded directories on gateway Jul 21, 2018
License: MIT
Signed-off-by: Łukasz Magiera <[email protected]>
@@ -1,3 +1,5 @@
// +build !noplugin
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a git add ..

License: MIT
Signed-off-by: Łukasz Magiera <[email protected]>
@magik6k
Copy link
Member Author

magik6k commented Jul 21, 2018

should be ready

@magik6k magik6k changed the title [WIP] Fix resolving links in sharded directories on gateway Fix resolving links in sharded directories on gateway Jul 21, 2018
@magik6k magik6k requested a review from Stebalien July 21, 2018 17:30
continue
}

val, rest, err := nd.Resolve(p)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is 'rest' not used?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems right (although rest should probably be _). This last resolve step is just to make sure that the rest of the path can be resolved. However, the function is only supposed to resolve up to the last node (it returns that last node and the rest of the path through this object).

Although, unless I'm mistaken, rest should be empty. It might make sense to check that.

return nil, nil, err
}
lnk, rest, err := r.ResolveOnce(ctx, r.DAG, nd, p)
if lnk != nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we could clean this loop up a little bit by pulling everything below this if statement out of the for loop, then reversing the logic to 'break' if lnk == nil

License: MIT
Signed-off-by: Łukasz Magiera <[email protected]>
@@ -69,25 +69,42 @@ func (r *Resolver) ResolveToLastNode(ctx context.Context, fpath path.Path) (ipld
}

for len(p) > 0 {
val, rest, err := nd.Resolve(p)
lnk, rest, err := r.ResolveOnce(ctx, r.DAG, nd, p)
if lnk == nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This'll drop the error, as far as I can tell.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We actually have to drop the error here as ResolveOnce will try to either resolve to a full node or to a link (so for echo '{"foo":123}' | ipfs dag put, trying to resolve /foo it would return an error)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, interesting. Can we make sure to document that explicitly? At a glance, it looks wrong, so let's make sure nobody comes along and 'fixes' it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably remove the error check below in that case.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can technically still be set at that point, but that would be a rather weird edge case

Copy link
Member

@whyrusleeping whyrusleeping left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, thanks for the fix @magik6k :)

@whyrusleeping whyrusleeping merged commit 4215653 into master Jul 23, 2018
@ghost ghost removed the status/in-progress In progress label Jul 23, 2018
@whyrusleeping whyrusleeping deleted the fix/5270 branch July 23, 2018 19:53
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

Successfully merging this pull request may close these issues.

3 participants