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>
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>
This allows for shell callers to just get a simple diff of what files
changed between the two invocations of go-mtree. This is somewhat
similar to supplying -f twice to the BSD mtree (though that compares two
specs and also gives you information about what *kind* of change
occurred).
Signed-off-by: Aleksa Sarai <asarai@suse.de>
This is far easier to parse than the default raw format, and provides
the full serialised result structure.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
This allows callers to deal with multiple output formats and not require
string parsing in order to understand what the error was. The default
format is "bsd".
Signed-off-by: Aleksa Sarai <asarai@suse.de>
When checking if a new set is needed (curSet != nil),
curSet wasn't being filtered against the actual keywords
a user specifies. Thus, if `defaultSetKeywords` includes "flags", but
the `keywords` argument for Walk() doesn't include "flags", "flags"
was included in the new \set, which isn't expected behavior. Instead,
we want to use keywordSelector function to make sure that we use
intended user-specified keywords.
Signed-off-by: Stephen Chung <schung@redhat.com>
The FreeBSD flag `-l` is already used and has differing behavior, so
switch to not conflict
Reported-by: Aleksa Sarai <asarai@suse.de>
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Comments were only ignored if the string parsed
started with "#". This commit trims leading whitespace
and tab characters to make sure all lines with "#" being the
first non-whitespace character are ignored.
Signed-off-by: Stephen Chung <schung@redhat.com>
Fixes#7. Upper 3 bits are 'special' mode bits, and are not
included when calling info.Mode().Perm(). Need to mask
the info.Mode() with the corresponding mode bit defined
by the go library to see if these bits are set or not.
Signed-off-by: Stephen Chung <schung@redhat.com>
Resolves#21. When using `-k` option, gomtree should use
only the keywords specified by the user, as well as the 'type'
keyword if it wasn't specified.
Signed-off-by: Stephen Chung <schung@redhat.com>
When iterating over creator.DH.Entries using the variable
e, and then setting creator.curSet to &e, this causes aliasing
that results in the underlying Entry of creator.curSet to
change on each iteration. Instead we want to get the address of
the actual Entry in creator.DH.Entries.
Signed-off-by: Stephen Chung <schung@redhat.com>