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>
behavior ought to be, when `-f <file>` is not provided, then expect the
manifest to be provided on stdin.
Currently gomtree just fails if there is no `-f` (and it is not `-c`)
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
This would help us build go-mtree on RHEL/CentOS and
distros where golang.org/x/crypto isn't provided or supported.
Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
This allows for xattr keywords to include spaces and other such options
(which is perfectly valid according to the definition of Lsetxattr --
any character except '\x00' is fair game).
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Because of how xattr works (it will not be set on all files, but it's
possible for it to be added to a file without changing any other key)
it's necessary that we _always_ compute a diff when we hit an inode that
has xattr keys set.
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>
Aleksa Sarai
Vincent Batts