diff options
| author | Matthew Heon <mheon@redhat.com> | 2021-02-15 11:58:24 -0500 |
|---|---|---|
| committer | Matthew Heon <mheon@redhat.com> | 2021-02-16 09:21:49 -0500 |
| commit | 759fc933438dead681a0c4f3d9e17826b0dc18cc (patch) | |
| tree | 1953cad9d200147d202b8033de5597b8f9ca8001 /libpod/boltdb_state_linux.go | |
| parent | 6639b218a28301e6e8d075cceb18c56ea62fcade (diff) | |
| download | podman-759fc933438dead681a0c4f3d9e17826b0dc18cc.tar.gz podman-759fc933438dead681a0c4f3d9e17826b0dc18cc.tar.bz2 podman-759fc933438dead681a0c4f3d9e17826b0dc18cc.zip | |
Fix an issue where copyup could fail with ENOENT
This one is rather bizarre because it triggers only on some
systems. I've included a CI test, for example, but I'm 99% sure
we use images in CI that have volumes over empty directories, and
the earlier patch to change copy-up implementation passed CI
without complaint.
I can reproduce this on a stock F33 VM, but that's the only place
I have been able to see it.
Regardless, the issue: under certain as-yet-unidentified
environmental conditions, the copier.Get method will return an
ENOENT attempting to stream a directory that is empty. Work
around this by avoiding the copy altogether in this case.
Signed-off-by: Matthew Heon <mheon@redhat.com>
Diffstat (limited to 'libpod/boltdb_state_linux.go')
0 files changed, 0 insertions, 0 deletions