Closed ghost closed 5 months ago
I think the short answer is that you are using made-up CID to retrieve data,
which has no providers, so it hangs while looking for them. If you use the one returned by ipfs add
it will work.
TLDR:
ipfs add
are chunked into smaller blocks that are always under this limit.ipfs add
is not guaranteed to be the hash of raw bytes.
ipfs add ./3M
represents a DAG built from two dag-pb blocks:
https://explore.ipld.io/#/explore/QmekBGp284QtNZoJg812EYkv3w55dNGt5Jxwjbg6g2ZRin
(the child block is present 11 times, because your file is filled with zeros, so repeating 256KiB chunk is repeated)I'm closing this (there is no bug in Kubo), but posting some resources for learning how IPFS handles files below.
The video course at:
And related docs:
For further support, try reaching out to https://discuss.ipfs.tech/c/help/13 (we limit github to bugs and feature requests), thanks!
Checklist
Installation method
built from source
Version
Config
Description
After a file is added to
kubo
withipfs add
, it cannot be retrieved from the API using the added file's hash.For example
The resulting base32 CIDs are also different
Edit: Doesn't work for raw binary with blake3 hashsum (f01551e200471c2e7ccc927709c1e41e299804f1c2d2c2b757ff5afd5a3172bd68b9bccc2)
Edit2: Specifically, it fails when trying to find the a block at this point https://github.com/ipfs/go-ds-flatfs/blob/3b1c91bc3097ec7702347d8a419269ce88e450b8/flatfs.go#L658 (found using breakpoints). Maybe there's something wrong with CID parsing? dunno....