InodeDelta comparison of FullType doesn't line up about go-mtree HOT 5 OPEN

example output

"cmd/gomtree/hierarchy_test.go": missing path
"README.md": unexpected path
"keywords_linux_test.go": unexpected path
".git/refs/tags/.travis.yml": missing path
"cmd/gomtree/mtree_test.go": missing path
"testdata/traversal/dir2/dir3/actualdir2/update.go": missing path
"glide.lock": unexpected path
"glide.yaml": unexpected path
"compare.go": unexpected path
".git/refs/tags/.vscode": missing path
"testdata/traversal/dir2/dir3/actualdir2/updatefuncs.go": missing path
"tar.go": unexpected path

from go-mtree.

https://github.com/vbatts/go-mtree/blob/master/testdata/source.casync-mtree is an example of the mtree output

from go-mtree.

After looking at this quite a bit, I've become convinced it's actually a casync bug -- they aren't generating mtree-compatible output. I've opened systemd/casync#167 with proposals for fixing it and examples of what happens. The simple trick of adding .. after each type=dir causes validation to work with gomtree, but FreeBSD mtree disallows / in node names and so we need to have a more complete solution.

from go-mtree.

Hmmm. I've looked at this again. While I was wrong to say the format is not valid, casync prints every entry as though it's a FullType but it will happily output directory entries that do not have / (which makes them relative and thus affects the current directory). However I think there's a separate issue in go-mtree (FullTypes are treated as being able to change the current directory, which doesn't match the "spec"). I also have a feeling we don't handle the spec-required behaviour of allowing more than one FullType to reference the same path...

from go-mtree.

systemd/casync#267 should fix the casync side, and #188 fixes the core issues with FullType though I still am not sure what we should do in the multiple-entries-for-the-same-path case. At the moment we just use the attributes of the last one but I'm not sure if that's the behaviour BSD expects (the "spec" doesn't tell us the correct behaviour, but I suspect our current behaviour is correct).

from go-mtree.