During the rework of how xattr fields are handled, the comparison code
was not correctly updated. As a result, changes to xattrs would not be
detected in any form. This was detected in the umoci integration suite.
In addition, fix the dh.UsedKeywords logic so auto-detection works
correctly with prefix-based xattrs.
Fixes: ed464af779 ("*: xattr can Update()")
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Fixes#16
In attempt to close https://github.com/vbatts/go-mtree/issues/16 I've
uncovered that the update was missing a function for symlink.
Additionally the update was not even opperating on the correct directory
hierarchy.
I've uncovered that os.Chtimes follows the symlink, and presumably only
Linux has an obscure way to set the mtime/atime on a symlink itself. So
I've made a custom lchtimes().
Also Mode follows through the symlink, and symlinks only ever have a
mode of 0777, so don't set them.
Lastly, directories need to have their mtime/atime set in a reverse
order after all other updates have been done. This is going to require
something like a `container/heap` to be unwound.
Also, each updateFunc will _only_ perform the update if it is needed. Much less
invasive this way.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
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>
