car extract -f bafkr... (raw root cid) not possible

[agmap]

I am having some car files fetch with lassie which are raw root CIDs (bafk....)
I can't extract the car files using car extract -f <CID>
Getting error skipping raw root bafkr...

[willscott]

do you not want car get for this case?
Extract expects to work with unixfs data and in this case of a raw root there's no file name / metadata present to allow extraction.

[agmap]

No, I want to extract the content into a real file. It is a small image that is not packed into a directory.
And yes, I know the file name and extension are not included.

[willscott]

but that's what car get is doing - it's getting a specific block from the car, and putting it into a file

[agmap]

It is a single image that is smaller than 256kb, so it is “bafk”. --> car extract -f bafk....car --> not working
--> this image seems only one single block, because its small.

A image bigger than 256kb beginns with "bafy" --> car extract -f bafy....car --> working

So I am realy wonder?

And in the CLI I cant find car get command.
So how to extract that image. And why I need to use a different command for the same purpose??

[willscott]

https://github.com/ipld/go-car/blob/master/cmd/car/get.go#L37

car get-block

[agmap]

OK, that works
car get-block <CID>.car <CID> 1.png

But I also want to use car extract -f <CID>
Otherwise I always have to check first whether it is a small or a larger file and use different commands for the same purpose.

It would realy help car extract -f <CID> works for all files.
Can you plaese also look into my lassie issues I created on github?

[rvagg]

Reasonable request, the problem is here:

go-car/cmd/car/lib/extract.go

Lines 50 to 55 in ed334d8

	if root.Prefix().Codec == cid.Raw {
	if verbose {
	fmt.Fprintf(logger, "skipping raw root %s\n", root)
	}
	return 0, nil
	}

The complication is that if you've bundled your file without a containing directory, then all we have is a raw bytes block with no metadata, so we don't know its name and extracting it is a problem. We don't even know that this block is a "file" per se, it's just a block of bytes. Ideally you should be bundling your files wrapped in a directory - if using kubo there's a commandline option for that IIRC. It results in two blocks, but at least the first block contains metadata and it clearly indicates that the block is unixfs and therefore a file.

When we get to the condition I linked above, we could just extract the raw as a file with the CID as its name, and print to stderr that this was done because the root was not wrapped in a unixfs directory. The user needs some kind of warning that an assumption was made.

[agmap]

In about 69% of all my NFTs, the ipfs file links in the URI of the NFT are not wrapped in a directory. So the file name and file extension are missing.
Please extract the file in my filesystem with the CID as file name and either without file extension or extract the file extension from the file signatures.
When I load the CID with the public gateway ipfs.io and download the CID, it has the correct file extension. The browsers also seem to extract the file extension from the magic numbers / file signatures.
https://en.wikipedia.org/wiki/List_of_file_signatures
https://mark0.net/soft-trid-e.html
https://gist.github.com/qti3e/6341245314bf3513abb080677cd1c93b
https://www.garykessler.net/library/file_sigs.html