right now, Check() doesn't check for missing/extra files. So, for the
sake of this test, we don't want to do this check for extra/missing files
when we validate the validation manifest produced from a tar against
the "." root directory (which would be /testdata).
Signed-off-by: Stephen Chung <schung@redhat.com>
Default behavior (according to upstream mtree) for validating symlinks
is to just validate the link itself, not to follow it.
Signed-off-by: Stephen Chung <schung@redhat.com>
Instead of checking each time during keyword evaluation if
the keyword is "time", just remove it from the start and
replace it with "tar_time" (if necessary).
Signed-off-by: Stephen Chung <schung@redhat.com>
Resolves#56. Now, the Entry tree will be populated
under a common root (if necessary), so that a manifest can
be accurately generate from a tar file that has been
created using multiple directories.
Signed-off-by: Stephen Chung <schung@redhat.com>
To increase a user's control on how they validate a directory or
tar archive with a specification, it is helpful to know which
keywords are actually used in the spec provided. This way, the user
can see what keywords to use or not use with the '-k' or '-K' flags.
Signed-off-by: Stephen Chung <schung@redhat.com>
Previously, the symlink size reported by a archive/tar header
was 0. This is incorrect, as the size of a symlink should be
the size of its contents, which is just the path to where
the symlink points to. Thus, the size of this file would just
be len(Linkname).
Signed-off-by: Stephen Chung <schung@redhat.com>
Flattening within the readHeaders() function call was problematic
because readHeaders() is called as a goroutine; thus, as the
main program was calling `tdh.writeTo(os.Stdout)`, readHeaders() was
still in the process of flattening the tree structure. To get around this,
we now call flatten in ts.Hierarchy(), such that only when the main program
is ready to retrieve a "valid" DirectoryHierarchy from the archive, should
we flatten the tree.
Signed-off-by: Stephen Chung <schung@redhat.com>
Cleaned up some dead code, and made populateTree not
take in a *tar.Streamer argument, as the ts argument was
only used to set an error. The function now returns
an error (if any). Also made flatten not have to take in
a *tar.Streamer argument as well.
Signed-off-by: Stephen Chung <schung@redhat.com>
Rather than an arbitrary election of hashing the xattr value with SHA1
to avoid leaking the value. By going with base64 encoding it allows for
the possibility of restoring a directory with the values stored in the
manifest.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Currently, if you create a manifest with, say 'sha1', and another
manifest with 'sha1digest', gomtree will produce different output
with regard to the keyword name. I.e, `sha1=[...]` vs. `sha1digest=[...]`.
If we want to use synonyms for keywords, as well as align with upstream mtree
output, specifying 'sha1' and 'sha1digest' should impact gomtree's
in the same way.
Signed-off-by: Stephen Chung <schung@redhat.com>
To support either producing or checking manifests that are compatible
with upstream FreeBSD mtree(8) keywords, this flag will only operate on
upstream keywords. Completely ignoring non-upstream keywords, though
printing out an INFO to stderr for information purposes.
Example:
```bash
INFO: ignoring "xattrs" as it is not an upstream keyword
/set type=file nlink=1 mode=0664 uid=1000 gid=100
. size=4096 type=dir mode=0755 nlink=2 time=1469556206.235575511
[...]
```
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
my tar_stream_tar_time PR accidentally put the functionality
for when gomtree has no arguments inside an unreachable block.
Signed-off-by: Stephen Chung <schung@redhat.com>
Files don't close properly when `defer`ing inside
a for loop, since the surrounding function is still
iterating in a for loop. To fix this, just close the files
explicitly after `populateTree()` in `readHeaders()`
Signed-off-by: Stephen Chung <schung@redhat.com>
Added some more test cases for `vis`ing and `unvis`ing
strings, and a test case that walks/checks a directory with
filenames that require encoding. Had to change Path() to account
for possible errors Unvis() could return. Refactored Vis()/Unvis() into
go-mtree tar functionality as well.
Signed-off-by: Stephen Chung <schung@redhat.com>
Perhaps this is not completely ideal, because it brings in cgo.
And with the flags, it can have tailored experience.
I've added a basic test to ensure that the cases we're interested in are
covered.
This does not yet integrate the usage of Vis()/Unviz() into the manifest
create and compare.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
if the keyword "tar_time" is present when evaluating
an Entry, gomtree should use the tar_time when evaluating
the "time" keyword as well. This commit also adds a test that
makes sure "tar_time" wins against "time" if both are present.
Some minor clean-ups as well, such as checking if KeywordFunc[keyword]
actually retrieves a function.
Signed-off-by: Stephen Chung <schung@redhat.com>
Since the field in a tar header for each file only preserves seconds
precision, not nanosecond precision, let's handle it special. This will
allow for more custom case handling in Check()
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
This commit contains added features to go-mtree that allows
user to create an mtree spec with '-T' option when specifying
a tar archive. Users can also validate an mtree spec against
a tar archive with an mtree spec. Also for the test archive,
there is a mixture of files, and folders (empty & non-empty),
and symlinks (broken & unbroken).
Signed-off-by: Stephen Chung <schung@redhat.com>
Originally only returning `Sys.linkname` when evaluating
a tar header's link field. We want it to be in the form of
keyword=value instead.
Signed-off-by: Stephen Chung <schung@redhat.com>
when creating a manifest from, or validating, a stream like a tar
archive, it requires thinking about some of the functions differently
than walking a directory tree.
This is the beginning of allowing for such features.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
