Now that we have govis, move everything to using govis.{Vis,Unvis} and
then remove the cvis build tags (because that code no longer exists).
Signed-off-by: Aleksa Sarai <asarai@suse.de>
In certain circumstances (such as the manifest generation of a
filesystem as an unprivileged user) it is important to provide hooks
that override the default os.* implementation of filesystem-related
functions.
In order to avoid merging too much code from outside projects (such as
umoci) this is implemented by providing FsEval hooks to Walk() and
Check(). This allows for users of go-mtree to modify how filesystem
checks are done, without compromising the simplicity of go-mtree's code.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
The current Vis() and Unvis() are using the C implementation from
MTREE(8).
But that means that cgo is used, which is not always desired.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Since not every keyword applies to every type entry, include a comment
with the keywords the manifest was generated with.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Signed-off-by: Vincent Batts <vbatts@hashbangbash.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>
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>
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>
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>
Setting up sibling and parent relationships for entries, so they can be
easier to walk.
Also, making "keyword=value" easier to parse. This helps filtering.
Both of these ready us for checking/validating a hierarchy.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Initially only on linux platform, but could accommodate BSDs as well.
The keyword is rather a prefix of the key. So xattr keyword will have a
prefix of "xattr." followed by a suffix of its namespace and name.
The value stored in the manifest is the SHA1 digest of the extended
attribute's data.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
For the most part, all the keywords for a standard mtree spec now have a
function to produce the contents for a creator.
These are used in the "walk" function, and will be used next in the
"check" logic.
This is still a WIP, as the DirectoryHierarchy produced from the current
Walk() is not all-together a valid document.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
