Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add full support for CidV1 in Files API and Dag Modifier #4026

Merged
merged 16 commits into from
Oct 19, 2017

Conversation

kevina
Copy link
Contributor

@kevina kevina commented Jul 1, 2017

Closes #3989 #3921

Status: #4026 (comment)

@kevina kevina added the status/in-progress In progress label Jul 1, 2017
@kevina
Copy link
Contributor Author

kevina commented Jul 1, 2017

Tests are failing. Working on fixing.

Also plan to add a "--raw-leaves" option to the files api.

@kevina kevina force-pushed the kevina/files-raw-leaves branch 2 times, most recently from b2c7b6e to a740592 Compare August 8, 2017 22:19
@kevina kevina changed the title WIP: Add full support for raw leaves in files API and Dag Modifier Add full support for raw leaves in files API and Dag Modifier and more Aug 9, 2017
@kevina
Copy link
Contributor Author

kevina commented Aug 9, 2017

Support for raw leaves is done.

I am going to tack on full CifV1 support and also support for setting a alternative hash function since they are very closely related. If necessary I can separate out CidV1 support into a new commit.

@kevina kevina changed the title Add full support for raw leaves in files API and Dag Modifier and more Add full support for CidV1 in Files API and Dag Modifier Aug 13, 2017
@kevina kevina added the need/review Needs a review label Aug 13, 2017
@kevina
Copy link
Contributor Author

kevina commented Aug 13, 2017

Full support for CidV1 (including using an alternative hash function is now done) using the following strategy (slightly modified from #3921 (comment))

  1. When a file or directory is modified the new hash and any new interior nodes in the dag will use the same prefix (which will preserve the Cid version and hash function).
  2. When a new file or directory is created it will use the same prefix as the directory it is added to, by default. The --cid-version and --hash-fun option can be used to specify a different prefix instead.
  3. If the Cid version is 0 legacy leaf nodes will be used, otherwise raw leaves will be used. This behavior can be changed by using the --raw-leaves option when modifying a file.
  4. In order to be able to change the MFS root I added a update command to the files api. When called it will update the prefix (cid version and hash function) of a directory.

If any part of this is controversial or needs more though it can easily be factored out of this P.R. and into a new one.

@kevina
Copy link
Contributor Author

kevina commented Sep 2, 2017

@whyrusleeping this has been ready for review for awhile now

The only outstanding issue if the files update command (ref #4171) which is needed to update the root to something other than CIDv0. This part doesn't have to go in, but many of the tests currently rely on it and will have to be redone.

I wrote a new utility cid-fmt (see ipfs/go-cid#31) which can greatly help with these tests.

root.Prefix = prefix
}

err = mfs.Mkdir(root, dirtomake, dashp, flush)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hrm.. this is getting complicated. Its starting to feel like we need some sort of MkdirOpts here that hold the dashp, flush, and prefix options for the operation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would work. Are you thinking:

mfs.Mkdir(root, dirtomake, mfs.MkdirOpts{Dashp: dashp, Flush: flush, Prefix: prefix})

@@ -756,6 +794,69 @@ are run with the '--flush=false'.
},
}

var FilesUpdateCmd = &cmds.Command{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not yet sold on update as the command name, but its an okay placeholder for now.

@@ -756,6 +794,69 @@ are run with the '--flush=false'.
},
}

var FilesUpdateCmd = &cmds.Command{
Helptext: cmds.HelpText{
Tagline: "Change the cid version of hash function of the root node of a given path.",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/of/or/

Also, given this description, maybe we should call the command re-cid ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about chcid?

Helptext: cmds.HelpText{
Tagline: "Change the cid version of hash function of the root node of a given path.",
ShortDescription: `
Flush a given path to disk. This is only useful when other commands
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ShortDescription needs fixing

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, will fix.

`,
},
Arguments: []cmds.Argument{
cmds.StringArg("path", false, false, "Path to flush. Default: '/'."),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

update text here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, will fix.

func getFileHandle(r *mfs.Root, path string, create bool) (*mfs.File, error) {
func getPrefix(req cmds.Request) (*cid.Prefix, error) {
cidVer, cidVerSet, _ := req.Option("cid-version").Int()
hashFunStr, hashFunSet, _ := req.Option("hash-fun").String()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm not sure we should use hash-fun. ipfs add just uses --hash, i'm thinking we should be consistent.

Copy link
Contributor Author

@kevina kevina Sep 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@whyrusleeping That won't work. The --hash option is already used in one of the sub-commands and will create a conflict.

// ^^fixme: can't use just "hash" as the option name as the
// conflicts with "--hash" usage by the stat command, this is
// unfortunate as it creates an inconsistency with the "add"
// that uses "hash"
},
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@whyrusleeping here is the comment on why I can't use "hash" as the option name

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we just have the --hash option for stat be different from the one on the other commands?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could, if you are willing to change the interface for stat. That is something I didn't want to do.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@whyrusleeping another option is to use --mhash instead of --hash-fun this is more specific (multi-hash) and is a good name for eventually making it a global option.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still don't think this is blocking anything. Stat is a separate command, it can have a flag that means something different, having those options on the ipfs files command doesnt make sense for a lot of cases too. ipfs add, which will at some point be moved under the ipfs files command also uses --hash. We need to stay consistent here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stat is a separate command, it can have a flag that means something different

Not with the current API. Currently the --hash-fun function is a global option for all ipfs files command. The ipfs files stat commandalso has the--hashoption. It creates this error when thestat` command is used:

$ ipfs files stat
Error: Option name 'hash' used multiple times

To resolve this conflict I need to either move the --hash option into each of the subcommands, or rename the --stat option in ipfs files stat to something else. If I move the --hash option to each of the subcommands I should likely move the --raw-leaves and --cid-ver option also to be consistent.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently the --hash-fun function is a global option for all ipfs files command.

dont do that.

I need to either move the --hash option into each of the subcommands

Yes, do that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@kevina
Copy link
Contributor Author

kevina commented Sep 11, 2017

@whyrusleeping I pushed some commits to address your feedback, I changed update to chcid.

@@ -97,16 +97,17 @@ test_sharding() {
}

test_files_api() {
local EXTRA ARGS
local EXTRA ARGS WRITE_ARGS
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did you mean to call this RAW_LEAVES ?

@whyrusleeping
Copy link
Member

Alright, this looks good to me. Going to need to rebase, and then it would be nice to have a few more of the codeclimate issues resolved before merging.

License: MIT
Signed-off-by: Kevin Atkinson <k@kevina.org>
License: MIT
Signed-off-by: Kevin Atkinson <k@kevina.org>
License: MIT
Signed-off-by: Kevin Atkinson <k@kevina.org>
License: MIT
Signed-off-by: Kevin Atkinson <k@kevina.org>
@kevina
Copy link
Contributor Author

kevina commented Oct 19, 2017

@whyrusleeping rebased and cleaned up some of the codeclimate issues

License: MIT
Signed-off-by: Kevin Atkinson <k@kevina.org>
License: MIT
Signed-off-by: Kevin Atkinson <k@kevina.org>
License: MIT
Signed-off-by: Kevin Atkinson <k@kevina.org>
License: MIT
Signed-off-by: Kevin Atkinson <k@kevina.org>
License: MIT
Signed-off-by: Kevin Atkinson <k@kevina.org>
License: MIT
Signed-off-by: Kevin Atkinson <k@kevina.org>
License: MIT
Signed-off-by: Kevin Atkinson <k@kevina.org>
License: MIT
Signed-off-by: Kevin Atkinson <k@kevina.org>
License: MIT
Signed-off-by: Kevin Atkinson <k@kevina.org>
License: MIT
Signed-off-by: Kevin Atkinson <k@kevina.org>
License: MIT
Signed-off-by: Kevin Atkinson <k@kevina.org>
License: MIT
Signed-off-by: Kevin Atkinson <k@kevina.org>
@whyrusleeping whyrusleeping merged commit e1f158b into master Oct 19, 2017
@whyrusleeping whyrusleeping deleted the kevina/files-raw-leaves branch October 19, 2017 22:56
@whyrusleeping
Copy link
Member

Thanks @kevina! we're entering the brave new world of cidV1..

@kevina
Copy link
Contributor Author

kevina commented Oct 19, 2017

Your Welcome. I image there is still more work to do, but this should hopefully make CidV1 practical to use by default. :)

@kevina kevina removed need/review Needs a review status/in-progress In progress labels Oct 20, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants