add CTRL+e for extracting current focused file

[kaedwen]

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.
#224

[TheRealGramdalf]

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]

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]

• 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 <container_id> 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]

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]

^ 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]

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]

* 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]

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!

[DeanAyalon]

I think this might not be working, at least, on my MacOS

I'm not savvy at Go, and I'm not sure which file runs for what purposes, but I see in some of the Extract functions, it simply logs "Not implemented" - Could it be the case for Mac as well?

And - How do I access the fmt log? So perhaps I can see what error my own machine is throwing when attempting to extract

Also, sorry where are the files extracted to? Perhaps it does work, but I just am looking in the wrong place

[wagoodman]

I agree, this functionality was pulled in already, however, I don't see it working as expected. I can dig further on this.