ipfs.files.add with {cidVersion: 1} returns valid hash with undefined size

[lidel]

This was originally found as a part of #1440 and ipfs/js-ipfs-http-response#9

• Version: js-ipfs 0.32.2
• Platform: Node
• Subsystem:

Type: Bug

Severity: High

Description:

For some inputs ipfs.files.add with {cidVersion: 1} returns valid CID however size field is undefined. The problem does not occur if {cidVersion: 0} is used.

Result of ipfs.files.add (CIDv0)

{ path: 'Qma4hjFTnCasJ8PVp3mZbZK5g2vGDT4LByLJ7m8ciyRFZP',
    hash: 'Qma4hjFTnCasJ8PVp3mZbZK5g2vGDT4LByLJ7m8ciyRFZP',
    size: 20 }

Result of ipfs.files.add (CIDv1)

{ path: 'zb2rhdTDKmCQD2a9x2TfLR61M3s7RmESzwV5mqgnakXQbm5gp',
    hash: 'zb2rhdTDKmCQD2a9x2TfLR61M3s7RmESzwV5mqgnakXQbm5gp',
    size: undefined }

Steps to reproduce the error:

Did not look into details, but I attach test case that illustrates the issue: js-ipfs-add-cidv1-missing-size-bug-repro.zip.

To run it: yarn && yarn test (or npm install && npm test).
Hope this helps.

[alanshaw]

@achingbrain do you have some time to look into this one? Looks like it might be a bug in unixfs-engine.

[achingbrain]

Sure, I'll take a look

[achingbrain]

Found the issue, see #1591

@lidel thanks so much for providing the failing test as an example. However even after the fix is merged it'll still fail because it asserts that the reported size of the file added with the v1 CID is greater than the input buffer - the default behaviour for v0 CIDs was to wrap all data in protobufs but for v1 it's to have it as a raw node (e.g. just a buffer), so the reported size will be the same as the input buffer. Just so you know...