-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Conversation
- tweak ipfs-cli get to handle `raw` - tweak ipfs-core mapFile to handle `raw` fixes #3682 License: MIT Signed-off-by: Oli Evans <[email protected]>
packages/ipfs-core/src/utils.js
Outdated
@@ -103,28 +103,32 @@ const mapFile = (file, options = {}) => { | |||
name: file.name, | |||
depth: file.path.split('/').length, | |||
size: 0, | |||
type: 'file' | |||
type: file.type |
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.
Types are broken - output
has a type of IPFSEntry
- IPFSEntry.type
can only be 'dir'
or 'file'
. file.type
has more possible values than that so the typecheck fails.
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.
Just to check, should the value of output.type
be file
when file.type === 'raw'
?
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.
ok so i guess I need to push the "can't deal with objects or identity" check down into mapFiles.
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.
objects or identity
AFAIK these parts of UnixFS aren't used by anything.
should the value of output.type be file when file.type === 'raw'
Yes, unless go-ipfs does something different 🙂
License: MIT Signed-off-by: Oli Evans <[email protected]>
- mapFile doesn't handle all mapping object or identity types to an IPFSEntry, so throw if it finds one. This makes the cli behaviour match go-ipfs for ipfs get <cbor cid> License: MIT Signed-off-by: Oli Evans <[email protected]>
@achingbrain i think i have sated the type machine |
- add interface-core test for get with rawLeaves: true - remove cli test for "raw" as core normalises the type to "file" so it was not testing a valid conditon License: MIT Signed-off-by: Oli Evans <[email protected]>
Nope, more noodling was required. The cli test was failing was testing a condition that the core normalises out, so that is removed. Meanwhile the interface-core tests were missing a test for getting a block that was added with |
Linting is failling?
|
Also the new test doesn't seem to work over http:
|
yes i've been leaning on ci to lint and test as it's not working locally. am trying a
|
Do you have a rogue The |
running reset and install has fixed it. I'll get those checks green yet. |
License: MIT Signed-off-by: Oli Evans <[email protected]>
The only place I can see an issue could occur for fetching a rawLeaves node via the js-ipfs http api, that doesn't occur on the ipfs-core get path would be here js-ipfs/packages/ipfs-http-server/src/api/resources/files-regular.js Lines 146 to 148 in 42f166b
Is there an easy way to run the interface core get tests against my local js-ipfs code and see the server side console log output? I've running |
Run with the $ DEBUG=ipfs* npm run test:interface:http-js -- -- -- --grep 'should get a file added as CIDv1 with rawLeaves' It's probably more legible if you run it from the $ cd packages/ipfs
$ DEBUG=ipfs* npm run test:interface:http-js -- --grep 'should get a file added as CIDv1 with rawLeaves' |
License: MIT Signed-off-by: Oli Evans <[email protected]>
the |
/** @type {import('ipfs-core-types/src/root').IPFSEntry} */ | ||
const output = { | ||
cid: file.cid, | ||
path: file.path, | ||
name: file.name, | ||
depth: file.path.split('/').length, | ||
size: 0, | ||
size: file.size, |
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.
is it legit to pass through the raw size for a raw node?
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.
Yes, it'll be the size of the block
CI failure is dns related, I've restarted the job & will merge when it's green. |
Shipped in |
raw
raw
fixes #3682
License: MIT
Signed-off-by: Oli Evans [email protected]