This is a gnarly patchset that has been mashed together.
It uncovered that some aspects of Check were never really working
correctly for `xattr` keywords, but also the `Update()` had been left
undone for a while.
This includes some API changes around the `Keyword` and `KeyVal` types.
Also I would like to update the signature for the `UpdateKeywordFunc` to
just accept a `KeyVal` as an argugment, rather than a keyword AND the
value. with this context there would be no need to guess on the value of
what's passed to the xattr update function of whether it needs or
already is base64 encoded.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
KeyVal specific functions can be a part of the struct.
Also add tests and fix the NewValue functions for suffixes
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
while testing on osx, it seems that it doesn't support nanoseconds so it
fails this check because the mockFsEval returns the nsec precision, but
the actual expected results is:
"old": "1337888911.288518233"
"new": "1337888911.000000000"
Ideally there will be a way to detect when the fs supports nsecs
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
This allows for restoring some attributes of files from the state in an
mtree Manifest
Reported-by: Matthew Garrett <Matthewgarrett@google.com>
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
This wraps up the govis changes. While umoci has much more hardcore
tests for unicode, this is done to ensure that go-mtree won't break
before its vendored into umoci.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
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>
govis is a reimplementation of vis(3) and unvis(3) specifically made to
be unicode aware. It was specifically rewritten to replace cvis and the
other go vis reimplementation we have in go-mtree.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
This is necessary to ensure that strings I don't have examples of work
properly. The same thing applies for double-encode and double-decode
usecases.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
This results in all multi-byte characters to be encoded in a way that
naive unvis(3) implementations will not bork up the encoding. In
addition, it also ensures that the output of Vis will always be ASCII
*only*.
Also test far more cases in *_test.go when it comes to different flags,
and do far more tests to ensure that the output of Vis() makes sense.
These outputs come directly from vis(3) and so are useful regression
tests to ensure that the handling of Vis() is identical to the original.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
While these characters are really weird to handle, here is a fairly
simple implementation that need some more testing (and a proper
secondary source to compare against).
Signed-off-by: Aleksa Sarai <asarai@suse.de>
In particular, previously such escape handling would break because we
would attempt to encode characters >0x7f as runes -- which would then
result in escapes that want to encode multi-byte characters breaking.
There's still some work necessary in Vis() to make it act sanely when it
comes to arbitrary bit streams. Not to mention that we need to figure
out what we actually want to do there...
Signed-off-by: Aleksa Sarai <asarai@suse.de>
This is a stopgap while I figure out how I should go about implementing
vis(3). It's also important to have some vis(3) implementation so I can
do integration tests on round-trips.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Also add some unit tests -- one of which currently fails due to ongoing
design discussion about how certain escape codes should be handled.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Because the original code for vis() was ported to Go using the []byte{}
notion, this causes issues for multi-rune bytes (which were not
correctly treated -- and caused loss of information).
Fix this by dealing with []rune instead, which better conveys the
concept at hand. In addition, add tests to ensure that this does not
happen again.
Though, we _really_ should move this code into a library which has a
better test suite -- and the parser itself should be reimplemented to be
less ... 80s.
Fixes: #118
Signed-off-by: Aleksa Sarai <asarai@suse.de>
