simple plain code api to create DirectoryHierarchy

[vbatts]

ref: https://twitter.com/paultag/status/936063255948165120

@paultag

Hey @vbatts - I'm looking at using go-mtree -- is there an easy way to create a new DirectoryHierarchy in plain code (e.g. no archive or filesystem tree exists)? The Entry pointers look nested enough to where I don't want to do that by hand :)

@vbatts

hey! good question. I haven't put thought to crafting one up in plain code. What do you have? os.FileInfo?

@paultag

Worse than that, sadly - just a path and a single key/value to set; it's not a standard use-case, and a "lolno" answer is maybe the right one :)

@vbatts

lolno is not the answer, but i haven't considered the case to make it easy. Are we talking like the output of libarchive/bsdtar mtree? or casync mtree?

[paultag]

Oof, I should have filed a bug, thanks for doing this!

I'm also OK sending a PR and refactoring the existing code to use it if this is a feature we need

[vbatts]

@paultag

It's for some experimental work on the .deb format - I'm generating ima signatures and putting those into the control member as an mtree to test out some work @mjg59 did on dpkg

[paultag]

It isn't pretty, but doing:

            dh.Entries = append(dh.Entries, mtree.Entry{
                Name: name,
                Keywords: []mtree.KeyVal{mtree.KeyVal(value)},
            })

And using dh.WriteTo(os.Stdout), the output looks correct. It appears as though if you don't set the right Directory tree, nothing really catastrophic happens. That's largely good enough for my use case!

[vbatts]

@paultag ok. That is what I was generally thinking, where position, parent, next and prev are not hard required but rather just used as available. You may want to set Type as FullType. Which, if you write this out, say to a tee, then passed it to mtree.ParseSpec(), it may parse that way.

I'd like to add some tests for this regardless. In investigating this issue, i've found that the mtree output from casync mtree parses nicely, but our current InodeDelta comparison doesn't handle that well. Need to open an issue for this.