I understand this, but this is currently not possible.
Can you give a concrete example, where it’s necessary to ask for this informations?
Well, the reason for this limitation is, for IPFS is firstly everything one thing: blocks. So there’s not a dedicated ‘metadata’ vs ‘data’ separation on the network side.
If you do a ipfs refs <CID there will be just the blocks fetched which are necessary to answer this ‘question’. If the CID belongs to a file, it’s likely that only the first block (default block size is 256 KByte) will be fetched. If the CID belongs to a directory, the size might be up to 1 MB at the moment, depending on the amount of files stored in the directory. If you have sharding enabled, the directory will be split in multiple blocks, and thus might be larger than 1 MB.
Note: A directory is usually pretty small.
As an example:
$ ipfs files ls /exampledir | wc -l
$ ipfs block stat QmRa6nnXCu9BCMZ3PmSpd4aKrry35otbwWR8umK3H994Fo
True. It also takes a while until IPFS gets back its network connections.
Yes, but not on the same block store/datastore. If a process is already running, it will create a lock file.
Let’s assume I have only the parent-hash and ipfs --offline refs -r returns False for it.
Now I want to check its hashes that are returned from ipfs refs -r one by one. When I do ipfs refs -r ipfs won’t download the full data itself right? instead it should downloads small amount of data only do obtain results for ipfs refs -r or ipfs object stat right?
Depends what data. IPFS can traverse arbitrary DAGs. It is not the same to to refs -r on a file added by default, vs a file added with trickle dag, vs a file added with raw leaves vs some random IPLD structure. In general, in order to list the children of a DAG, you need to download that DAG node.
In the normal case, those DAG nodes which are not leaves will be relatively small. But I cannot ensure they are not downloaded with refs -r.
If you want to go little by little you can do ipfs refs (without the -r) and traverse manually. Does that help?