foofoo.block has more links than UnixFS Blocksizes

[schomatis]

I'm refactoring the DAG reader (#5257) and I'm having an error in the test file t0110-gateway.sh where the foofoo.block file, which is saved as a block and retrieved as a file DAG through the gateway, would appear to have an inconsistency between its number of DAG links and its number of UnixFS Blocksizes, is this expected in the test? If not, how could I regenerate that file with the UnixFS format fixed?

/cc @magik6k

[kevina]

This is not broken.

Please see #4680 (comment) and #4286 (comment).

[schomatis]

Thanks for the references @kevina, I'll take a closer look at them. From a first read I'm understanding that UnixFS Blocksizes might be optional, I guess my question then is, to make the DAG reader comply with the standard expected behavior, if there is indeed a mismatch between those two indicators, what should be the correct response when seeking? I'll keep reading to see if I can find the answer there.

[kevina]

@schomatis yes please see #4680 as is is closely related.

[schomatis]

So, reading the PR that added this test, #4320, I understand that this is testing how to handle a UnixFS file that has no Blocksizes, and the answer seems to be rely on the UnixFS Filesize, @magik6k, is this correct? I can rely on the UnixFS Filesize and I should not trust Blocksizes (using instead the DAG links)?

[schomatis]

Fixed with a777290.

[magik6k]

AFAIK We want to relay on Blocksizes if they are present and defer to Filesize only if we really need to. See #4680 (comment) for better explanation/interpretation.

[schomatis]

Yes, my question was mostly oriented to how should the reader behave with the gateway to pass this particular test (the other seems to be a discussion for a long term solution), I understand now that -1, nil should be returned without moving the offset when there are no Blocksizes.