Difference of paths between recursive and normal calls #43
Labels
status/ready
Ready to be worked
Comments
|
I think this is meant to be a reflection of what happens in bash, etc. Given: $ ls -l foo
total 3
-rw-r--r-- 8 alex staff 256 4 Oct 16:22 bar.txt
drwxr-xr-x 12 alex staff 384 8 Oct 11:52 baz$ ls -lR foo
total 3
-rw-r--r-- 8 alex staff 256 4 Oct 16:22 bar.txt
drwxr-xr-x 12 alex staff 384 8 Oct 11:52 baz
foo/baz:
total 2
-rw-r--r-- 1 alex staff 838 20 May 15:44 qux.txtIn the second example the containing folder becomes part of the path - it prints That said, it'd certainly be simpler if it only worked one way, probably the second where the paths contain the |
achingbrain
referenced
this issue
in ipfs/js-ipfs
Oct 17, 2019
* sanitises input to replace multiple slashes with single slashes * removes trailing slashes * uses `0` for padding when `link.depth` results in negative padding N.b will be resolved in a better way by ipfs/js-ipfs-unixfs-exporter#24
|
For info: We agreed that the depth will be calculated as using full path. Hence returns it will have depth 2. |
achingbrain
referenced
this issue
in ipfs/js-ipfs
Oct 17, 2019
* sanitises input to replace multiple slashes with single slashes * removes trailing slashes * uses `0` for padding when `link.depth` results in negative padding N.b will be resolved in a better way by ipfs/js-ipfs-unixfs-exporter#24
achingbrain
referenced
this issue
in ipfs/js-ipfs
Oct 17, 2019
* sanitises input to replace multiple slashes with single slashes * removes trailing slashes * uses `0` for padding when `link.depth` results in negative padding N.b will be resolved in a better way by ipfs/js-ipfs-unixfs-exporter#24
achingbrain
referenced
this issue
in ipfs/js-ipfs
Oct 17, 2019
* sanitises input to replace multiple slashes with single slashes * removes trailing slashes * uses `0` for padding when `link.depth` results in negative padding N.b will be resolved in a better way by ipfs/js-ipfs-unixfs-exporter#24
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As part of ipfs/js-ipfs#2540 I was digging why there are different
link.depthwhenipfs lsis called recursively and non-recursively. I have tracked the inconsistency to how this exporter returns paths when called recursively and non-recursively.When called using
/ipfs/Qmaj2NmcyAXT8dFmZRRytE12wpcaHADzbChKToMEjBsj5Z/init-docsrecursivelly, the result paths are:QmUhUuiTKkkK8J6JZ9zmj8iNHPuNfGYcszgRumzhHBxEEU/contactQmUhUuiTKkkK8J6JZ9zmj8iNHPuNfGYcszgRumzhHBxEEU/aboutWhen called using
/ipfs/Qmaj2NmcyAXT8dFmZRRytE12wpcaHADzbChKToMEjBsj5Z/init-docsnon-recursivelly, the result paths are:Qmaj2NmcyAXT8dFmZRRytE12wpcaHADzbChKToMEjBsj5Z/init-docs/contactQmaj2NmcyAXT8dFmZRRytE12wpcaHADzbChKToMEjBsj5Z/init-docs/aboutEq. the original
/init-docsis suddenly part of the returned paths.I believe there should be one way for both ways. What should be the right one?
The text was updated successfully, but these errors were encountered: