New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
composefs: committing the finished image: failed to put layer using a partial pull: rename xxx/diff: no such file or directory #1915
Labels
Comments
|
we should not be so aggressive to cleanup the staging directory: storage/drivers/overlay/overlay.go Line 883 in 3cbd3c6
I am not sure yet how to address it, I'll keep working on this |
giuseppe
added a commit
to giuseppe/storage
that referenced
this issue
Apr 30, 2024
lock any staging directory while it is being used so that another process cannot delete it. Now the Cleanup() function deletes only the staging directories that are not locked by any other user. Closes: containers#1915 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
giuseppe
added a commit
to giuseppe/storage
that referenced
this issue
Apr 30, 2024
lock any staging directory while it is being used so that another process cannot delete it. Now the Cleanup() function deletes only the staging directories that are not locked by any other user. Closes: containers#1915 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
opened a PR: |
giuseppe
added a commit
to giuseppe/storage
that referenced
this issue
Apr 30, 2024
lock any staging directory while it is being used so that another process cannot delete it. Now the Cleanup() function deletes only the staging directories that are not locked by any other user. Closes: containers#1915 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
giuseppe
added a commit
to giuseppe/storage
that referenced
this issue
Apr 30, 2024
lock any staging directory while it is being used so that another process cannot delete it. Now the Cleanup() function deletes only the staging directories that are not locked by any other user. Closes: containers#1915 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
giuseppe
added a commit
to giuseppe/storage
that referenced
this issue
May 2, 2024
lock any staging directory while it is being used so that another process cannot delete it. Now the Cleanup() function deletes only the staging directories that are not locked by any other user. Closes: containers#1915 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
giuseppe
added a commit
to giuseppe/storage
that referenced
this issue
May 2, 2024
lock any staging directory while it is being used so that another process cannot delete it. Now the Cleanup() function deletes only the staging directories that are not locked by any other user. Closes: containers#1915 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
giuseppe
added a commit
to giuseppe/storage
that referenced
this issue
May 2, 2024
lock any staging directory while it is being used so that another process cannot delete it. Now the Cleanup() function deletes only the staging directories that are not locked by any other user. Closes: containers#1915 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The gist seems to be:
Seems to be remote-only.
Been trying all afternoon to reproduce this. I can't. So here are links to failure logs:
podman load from URL
testpod something infra something
testThe text was updated successfully, but these errors were encountered: