add CTRL+e for extracting current focused file

kaedwen commented 1 year ago

Added a way to extract the current focused item in the tree view. This is far from optimal and we can start discussing on it. https://github.com/wagoodman/dive/issues/224

TheRealGramdalf commented 10 months ago

This could use docker create and docker cp which would be much more efficient: https://unix.stackexchange.com/questions/331645/extract-file-from-docker-image

miskr-instructure commented 7 months ago

This could use docker create and docker cp which would be much more efficient:

docker cp requires tar to be installed in the image which makes that solution worse.
docker cp also requires the container to be running, so the entrypoint would need to be overwritten with a program that keeps running, this also requires specific binaries (eg. sleep/tail) to be present
it would be difficult to ensure that the container is deleted in every case (dive can get killed/terminated)
for small images, or if the file is early in the tar stream, the PR's solution is probably more efficient that waiting for docker to spin up a sandbox and run a process in it.

TheRealGramdalf commented 7 months ago

docker cp requires tar to be installed in the image which makes that solution worse.

I wasn't able to find anything that would indicate this - as far as I'm aware it just finds the file in the relevant /var/lib/docker/overlay2/* directory from the host.

docker cp also requires the container to be running, so the entrypoint would need to be overwritten with a program that keeps running, this also requires specific binaries (eg. sleep/tail) to be present

The answer I linked says otherwise: "According to the docker create documentation, this doesn't run the container:"

_The docker create command creates a writeable container layer over the specified image and prepares it for running the specified command. The container ID is then printed to STDOUT. This is similar to docker run -d except the container is never started. You can then use the docker start command to start the container at any point._

it would be difficult to ensure that the container is deleted in every case (dive can get killed/terminated)

This is a fair point. I'm not sure how exactly you would get around this, but it really shouldn't be that bad - a docker prune would easily fix this. Worst case scenario make dive create containers with a specific label (like --label wagoodman.dive.temp), and then check for containers with that label on next run (and notify the user to remove them/remove them automatically)

for small images, or if the file is early in the tar stream, the PR's solution is probably more efficient that waiting for docker to spin up a sandbox and run a process in it.

True, it might be. Except for the process point, since doesn't need to spin up the sandbox.

The only other thing I can think of is copying a file from an intermediate layer (that has been changed in a following layer) - I'm not sure if you can do that with docker cp, it doesn't look like you can

kaedwen commented 7 months ago

Hey @TheRealGramdalf, I would say that @miskr-instructure is right with the docker cp had this problem (hence the idea of using Dive and using it to extract files)

Try this

use a container FROM scratch, with just one file in it
try docker cp with it, it will complain about not having cp, and if you have it in there (busybox or whatever), the next missing is tar

miskr-instructure commented 7 months ago

^ You may be able to solve those by readonly-mounting cp and tar from somewhere outside, but those have the dynamic library dependencies (unless they are busybox-based) which you'd also need to mount in, etc...

All the solutions to this are more complex than the PR's. The only other trick would be directly accessing docker's image repo in the filesystem instead of going through the daemon, which is too brittle.

avan-pra commented 2 weeks ago

Hi, thanks a lot for your PR, I added the functionality to extract from local archives in my local repository (I don't think I can contribute code to this PR)

DeanAyalon commented 2 weeks ago

* docker cp requires `tar` to be installed in the image which makes that solution worse.

No?

FROM scratch
COPY --from=alpine /lib/apk/db/installed .
# Just a random text file

docker build . -t test
docker create test .
docker cp test:/installed .

File extracted successfully

* docker cp also requires the container to be running, so the entrypoint would need to be overwritten with a program that keeps running, this also requires specific binaries (eg. sleep/tail) to be present

Also wrong, it just needs to exist, it can be stopped.

* it would be difficult to ensure that the container is deleted in every case (dive can get killed/terminated)

That is correct, yes. @TheRealGramdalf good idea!

* for small images, or if the file is early in the tar stream, the PR's solution is probably _more_ efficient that waiting for docker to spin up a sandbox and run a process in it.

Have you looked into Crane? Perhaps this could supply with a better file extraction method?

TheRealGramdalf commented 2 weeks ago

No?

Glad to know I'm not going crazy. I've since stopped using docker for a lot of things, so I didn't end up trying that myself. Thanks @DeanAyalon!

wagoodman / dive

add CTRL+e for extracting current focused file #472