feat: OverlayFS -> AUFS whiteout conversion #55
Conversation
dtrudg
force-pushed
the
issue53
branch
3 times, most recently
from
a3b4797
to
f808c64
Compare
dtrudg
changed the title
Allow OverlayFS whiteouts to be converted to AUFS, by filtering a tar stream. In this direction the conversion is a single pass, single operation. There is no requirement to pre-scan the tar. Close sylabs#53
There was a problem hiding this comment.
LGTM. Just one observation, the round trip exposes that some of the TAR entries end up getting Cleaned, while others do not. I'm not aware of any specific issue this causes, but thought I'd raise it just in case you can think of any?
Specifically, the input in your test case is:
$ gunzip -c test/images/aufs-docker-v2-manifest/blobs/sha256/da55812559dec81445c289c3832cee4a2f725b15aeb258791640185c3126b2bf | tar tf -
./
./dir/
./dir/.wh..wh..opq
./.wh.file
When converted to OverlayFS, you end up with the whited out file trimmed of its ./:
$ tar tf 'pkg/mutate/testdata/Test_WhiteoutRoundTrip/overlayfs.golden'
./
./dir/
file
And then of course when you go back the other direction, both whiteout files have also been trimmed of their leading ./.
$ tar tf 'pkg/mutate/testdata/Test_WhiteoutRoundTrip/aufs.golden'
./
./dir/
dir/.wh..wh..opq
.wh.file
Right - they are equivalent, but yeah.. it would be nicer for comparison purposes if the |
|
@tri-adam - please take a look at 580119f |
Prior to this PR, when a tar file contains an entry prefixed with `./` that is processed by a whiteout transformation, the `./` prefix is lost. This loss of the prefix was due to the use of `filepath` functions that clean the resulting path. Instead, use `filepath.Split` and manual concatenation with filepath.Seperator` to avoid the clean.
Allow OverlayFS whiteouts to be converted to AUFS, by filtering a tar stream.
In this direction the conversion is a single pass, single operation. There is no requirement to pre-scan the tar.
Close #53