The core issue comes about when you consider a trivial example of a path
like "./README". This path is lexically equivalent within mtree to
"README", but a simple string comparison will yield the wrong result.
Instead you need to lexically clean the path first (filepath.Clean isn't
enough here -- you need to prepend a "/" and then do filepath.Clean).
In gomtree we generate spec files in the same style of FreeBSD's
mtree(8), so you would be very hard-pressed to find an example of such
an inconsistency. However casync's mtree implementation does not
generate leading "./" for root paths which results in "missing" entries.
The implementation of CleanPath was written by me for umoci originally,
then later I copied it to runc for other uses, and now I've copied it
here. Since I'm the sole author I'm effectively dual-licensing it under
this project's license to avoid having to relicense go-mtree for no good
reason (or deal with the multiple-license hassle).
Signed-off-by: Aleksa Sarai <asarai@suse.de>
This allows people to create synthetic InodeDeltas, which is something
that umoci would like to be able to do in order to nicely create 'umoci
insert' layers.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Use UtimesNanoAt from golang.org/x/sys/unix instead of manually crafting
the syscall.
Since UtimesNanoAt is provided for all unix-like OSes, factor out
lchtimes to its own file with appropriate build tags. This allows to
make use of it on darwin, dragonfly, freebsd, openbsd, netbsd and
solaris in addition to linux.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Vendor golang.org/x/sys to get the UtimesNanoAt function defined for all
unix-like OSes. The function will be used in a successive commit.
This also re-vendors the other dependencies from glide.yaml.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
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>
