Closed hannahhoward closed 2 years ago
Once unixfs reifier has been run on the outer traversal, wont it still be in effect at the point of matching? do you have an example of where the additional interpretAs is missing / would have an effect here?
I think it's only applicable in the degenerate case where there's only a single matcher with no path above it.
@willscott see the surrounding code -- ExploreInterpretAs only lasts as long as you don't exit the immediate ADL instance you're working with. You have to apply it at each level of the path. So for example if you're in a UnixFS directory, ExploreInterpretAs will last only until you go to a sub directory or a file. This is cause UnixFS directories don't automatically load links at their edges. Rather they return a node of type link that the selector traversal loads -- the problem is when the selector traversal loads the link, it loses the reification.
The code in question can be found here -- I believe at minimum go-path is expecting go-unixfsnode to behave this way -- https://github.com/ipfs/go-unixfsnode/blob/main/directory/basicdir.go#L36
I discovered this in the real world when I was working with the graphsync PR -- the last node was just being left an ordinairy DagPB.
Goals
At the end of pathing into a UnixFS directory, you encounter a UnixFS object (whether file, directory, symlink, etc). You almost always want to reify that node, rather than work with the base protobuf type. This has no effect on single block unixfs files, but for multiblock files and directories, this is the only way you can work with the resulting object properly for the visitor function.
Implementation
fix the selector for paths, wrapping the last matcher node in an ExploreInterpretAs, since the tail end of a path into a unixfs dir is itself a unixfsnode