fix: handle overlay xattr opaque bit #538
Conversation
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #538 +/- ##
==========================================
- Coverage 73.34% 73.28% -0.06%
==========================================
Files 60 60
Lines 4895 4908 +13
==========================================
+ Hits 3590 3597 +7
- Misses 944 949 +5
- Partials 361 362 +1
|
|
Looks like some delta between current main branch and the project-stacker branch, @rchincha . |
rchincha
force-pushed
the
overlay-opaque
branch
5 times, most recently
from
60783be to
e7a8957
Compare
Current behavior determines if a path is a whiteout if a overlay char dev is present. Additionally, also check the extended attrs. For files, this is not important: if a file /foo/bar exists in some two layers, then the higher layer's version will replace the lower layer's version whether or not the opaque bit is set. However, directories behave differently. If /foo exists in two layers and no opaque bit is set, then we see the union of their contents. But if the opaque bit is set on the higher layer's version, then we should not see the lower layer's version. So, in that case, create a whiteout /.wh_foo. Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
|
This behavior seems a bit fiddly; can you add a test to make sure it doesn't break in the future? I think that will also help describe what the problem is. |
|
Sorry for not responding earlier when you sent this -- my first impression when I looked at this a few months ago is that we might want to look at what containerd does, since they have to do conversions between the AUFS-style OCI tar entries to overlayfs files. But I need to look at this again, since I might be confusing what the issue is... |
Current behavior determines if a path is a whiteout if a overlay char dev is present.
Additionally, also check the extended attrs.