commands/block: use CIDv1 with custom mhtype #4563
Conversation
ghost
assigned 
|
Shouldn't this actually just return an error if the user passes |
magik6k
force-pushed
the
fix/block-mhtype
branch
from
4c180b8
to
dbe0074
Compare
|
Done |
magik6k
force-pushed
the
fix/block-mhtype
branch
from
dbe0074
to
3b5a78c
Compare
core/commands/block.go
Outdated
| var pref cid.Prefix | ||
| pref.Version = 1 | ||
|
|
||
| format, _ := req.Options["format"].(string) | ||
| format, userFormat := req.Options["format"].(string) |
There was a problem hiding this comment.
Unfortunately, userFormat will always be true there is a default value. The only way I know to fix this, is to simply remove the default.
magik6k
force-pushed
the
fix/block-mhtype
branch
2 times, most recently
from
9c43c2c
to
fd5479a
Compare
License: MIT Signed-off-by: Łukasz Magiera <[email protected]>
magik6k
force-pushed
the
fix/block-mhtype
branch
from
fd5479a
to
8c176d2
Compare
test/sharness/t0050-block.sh
Outdated
| @@ -209,4 +209,16 @@ test_expect_success "no panic in output" ' | |||
| test_expect_code 1 grep "panic" stat_out | |||
| ' | |||
|
|
|||
| test_expect_success "can set multihash type and length on block put without format" ' | |||
| HASH=$(echo "foooo" | ipfs block put --mhtype=sha3 --mhlen=16) | |||
There was a problem hiding this comment.
16 will be too short of a hash length after cid changes come through, please change it to 20.
License: MIT Signed-off-by: Łukasz Magiera <[email protected]>
core/commands/block.go
Outdated
| `, | ||
| }, | ||
|
|
||
| Arguments: []cmdkit.Argument{ | ||
| cmdkit.FileArg("data", true, false, "The data to be stored as an IPFS block.").EnableStdin(), | ||
| }, | ||
| Options: []cmdkit.Option{ | ||
| cmdkit.StringOption("format", "f", "cid format for blocks to be created with.").WithDefault("v0"), | ||
| cmdkit.StringOption("format", "f", "cid format for blocks to be created with.").WithDefault(""), |
There was a problem hiding this comment.
I wouldn't specify a default at all. As it is, passing -f "" will be considered valid even though it makes no sense.
If you don't specify a default, you can tell if the parameter was passed with format, formatSet := req.Options["format"].(string).
License: MIT Signed-off-by: Łukasz Magiera <[email protected]>
|
This PR looks correct to me (and it fixes the addressed issue) but let me raise an off-topic question: shouldn't part of this prefix preprocessing logic be in It seems to me there are a couple of hard-coded pieces of information of what constitutes a valid CID prefix that the The |
|
I think most of the processing here is due to 1. us wanting to provide good error messages for user 2. be lenient with the user input. One check in question (CIDv0 can only be full length SHA256) is currently not implemented but we are in process of changing that (https://github.com/ipfs/go-cid/pull/40/files#diff-beb384810133d725af6b502e9b6e3de8R139) I am not sure if go-cid would be right place to cover all of those areas but having a helper function somewhere in go-ipfs would not hurt. |
That's a good point I hadn't considered, but looking at the errors:
I think all of them can be outsourced without losing expressiveness for the user (the
That's fine, my main point wasn't where this logic should be placed but that it should be encapsulated somewhere outside this command function. Anyway, maybe this should be discussed in another issue after this PR is merged, trying to change all this here in this PR now would be to messy, but I wanted to leave this suggestion documented somewhere. |
|
I think the issue here is that we want to catch all of these errors early and provide reasonable defaults (that may change based on the command in question). However, we probably could have something in An alternative solution would be to add flag "sets" to go-ipfs-cmds and create a flag set for CID options somewhere. |
|
First PR merged of the 0.4.15 cycle goes to @magik6k :) 👏 |
Closes #4741 ~Kubuxu