The previous logic was overly complicated and can be simplified a lot
(especially now that we have helpful generic stdlib packages for dealing
with maps).
There are still several bugs in this, but the intention of this patch is
to just modernise the code without making any functional changes.
Bugfixes will come later.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
At the moment, filtering out keyword changes from an InodeDelta after
doing Compare is a little complicated and error-prone. The simplest
solution is to allow for callers to access a pointer to the underlying
slice so it can be modified properly.
The filtering logic in the gomtree command-line implicitly depends on
the behaviour of InodeDelta.Diff -- DiffPtr would be a far more
appropriate replacement.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
testify makes most bog-standard test checks much easier to read and
maintain, and is quite widely used. It wasn't really well known back
when govis was first written, but the migration is fairly
straight-forward for most tests.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
It seems that this test actually had a bug that was not caught until I
tried to refactor it. The new test has behaviour that makes more sense
to me.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
testify makes most bog-standard test checks much easier to read and
maintain, and is quite widely used. It wasn't really well known back
when go-mtree was first written, but the migration is fairly
straight-forward for most tests.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
This was added in Go 1.15 and avoids polluting the host /tmp with test
directories if the test crashes or is forcefully killed.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Rather than parsing the value as a float and then truncating it, just
parse it as an integer in the first place (this also adds some
validation that we are parsing a reasonable-looking value).
While we're at it, add some integration tests for this code to make sure
this quite complicated special-case behaviour doesn't regress.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
In certain circumstances, if a manifest with "time" keywords was
compared to another manifest with "tar_time" keywords, differences were
not actually reported despite there being logic for it.
Unfortunately, even though commit 26ff922da6 ("compare: implement
mtree.DirectoryHierarchy comparisons") explicitly included logic to
handle the necessary "time" -> "tar_time" conversions, the same commit
also made it so that Compare() could be instructed to only consider a
subset of keywords and failed to take into account said "time" ->
"tar_time" remapping.
Most users have likely not noticed this because gomtree will re-use the
keywords from a manifest when doing a straightforward "gomtree validate"
invocation, but if you explicitly requested "time" when validating a
"tar_time" manifest (and *not* the other way around) then any time
changes would be undetected.
Fixes: 26ff922da6 ("compare: implement mtree.DirectoryHierarchy comparisons")
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
frustratingly, `golang.org/x/sys/unix` started importing from `slices`
and didn't cleanly put the go headers version support, so all libraries
that used this library needed to be updated and could not take the
update without also updating to `go1.24`. So dumb.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
POSIX explicitly requires "set -e" to NOT treat "! cmd" as an error even
if fails[1]:
> The -e setting shall be ignored when executing the compound list
> following the while, until, if, or elif reserved word, *a pipeline
> beginning with the ! reserved word*, or any command of an AND-OR list
> other than the last. *[emphasis added]*
And bash has similar documentation on this behaviour[2].
This means that our tests were completely ineffective at detecting error
codes from gomtree, and as a result we did not detect the regression in
commit 83c9fdb78b ("refactor: prefactor for adding new subcommands").
The simplest solution (as done in this patch) is to just wrap all of the
failing examples in a subshell, which causes the shell to no longer
consider them exempt from "set -e". A more complete solution would be to
either switch to something like bats entirely or at least use something
like their "run" helper function to test for exit status codes
correctly.
[1]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#set
[2]: https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html
Fixes: 5d7f6c36e0 ("walk: directory is expected to be walked. A file is not.")
Fixes: 2d841d54bf ("test: testing the double -f comparison")
Fixes: f6c295f2e9 ("test: cli: add unicode verification test")
Fixes: 071977cef6 ("test: cli: add xattr tests")
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
This was broken during the refactor for "gomtree validate" in commit
83c9fdb78b ("refactor: prefactor for adding new subcommands"),
resulting in any code that relied on our exit code to silently treat all
errors as non-fatal.
Our tests did not catch this due to a quirky POSIX-ism with regards to
"! cmd" and "set -e" which is fixed in a follow-up patch.
Fixes: 83c9fdb78b ("refactor: prefactor for adding new subcommands")
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Update the README to show the validate subcommand by default.
This doesn't eliminate the default behavior of _not_ using the command,
but begins the visibility of using it by default.
Also copy one of the existing tests, to ensure the same behaviour works
as we add more subcommands and/or global flags.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
The spec[1] doesn't mention anything about cleaning paths, but it does
explicitly refer to the path containing a "/". Cleaning the path before
checking if the entry is a FullType would result in the simplest way of
forcing directories to be FullTypes (appending a "/" to the pathname of
any directory) not working with go-mtree.
[1]: https://man.netbsd.org/mtree.5
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
As per the spec[1], Full entries must not affect the current directory.
Handling this incorrectly caused us issues with certain manifests (ones
with mixed Relative and Full entries, which is something casync does by
accident).
This is a partial fix for the issues with verifying casync-mtree's
output but there are a few other issues to iron out (including one
within casync).
[1]: https://man.netbsd.org/mtree.5
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
oh dang, I released 0.5.2 and 0.5.3 without correctly setting the
version string :-\
Ideally this "-dev" is attempting to be like the git.
So, ditch the version in the library.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
