whisperingchaos/dkrcp

Copy files between Docker containers and images

dkrcp's Issues

Docker image MAINTAINER Author field containes tmp.<RandomString>

A bug in docker 1.8 would prevent deletion of an image if a container included a layer referencing an image's topmost layer even though the container was derived from another image that was different but included this same image layer.

To advert this problem, the initial SCRATCH image, used when creating an image's first layer is differentiated by executing MAINTAINER $(basename $(mktemp -u)) resulting in a unique top image layer for each image created by the dkrcp.

As a workaround, use the --change 'MAINTAINER <MaintainerName>' to set the Author field to a desired value.

This workaround strictly applies to Docker 1.8. In derivative Docker versions, dkrcp doesn't execute the MAINTAINER instruction, therefore, the Author field is unassigned.

Receive several messages like: "MessageInclude.sh: No such file or directory"

dkrcp set's its own PATH variable instance and in the situation where the working directory isn't dkrcp's install directory, a tilde path expression referencing dkrcp's install directory won't be properly expanded resulting in the generation of the "No such file or directory" message for each module dkrcp depends on.

#Ex: dkrcp installed to ~/Desktop/project/dkrcp and working directory is set to home:
:~$ ~/Desktop/project/dkrcp/dkrcp.sh  --help
/home/secure/Desktop/project/dkrcp/dkrcp.sh: line 15: MessageInclude.sh: No such file or directory
/home/secure/Desktop/project/dkrcp/dkrcp.sh: line 16: ArgumentsGetInclude.sh: No such file or directory
/home/secure/Desktop/project/dkrcp/dkrcp.sh: line 17: ArrayMapTestInclude.sh: No such file or directory
/home/secure/Desktop/project/dkrcp/dkrcp.sh: line 18: VirtCmmdInterface.sh: No such file or directory
/home/secure/Desktop/project/dkrcp/dkrcp.sh: line 19: CommonInclude.sh: No such file or directory
/home/secure/Desktop/project/dkrcp/dkrcp.sh: line 20: UcpInclude.sh: No such file or directory
/home/secure/Desktop/project/dkrcp/dkrcp.sh: line 21: ArgumentsMainInclude.sh: No such file or directory

Inherit metadata when creating a new image from an existing one.

If demanded, metadata, like ENTRYPOINT, can be 'inherited' from SOURCE image references when TARGET is a new image.

Workaround: use --change option to set metadata values for new images.

Command-line Completion doesn't work.

Command-line Completion not implemented.

Copy requests TARGETing the default root ('/') directory fail. "no such directory"

Situations relying on the stated "default root directory" expectation fail when they should succeed.
For example, the following command should copy the 'hostname' file to the targeted container's root ('/') directory:

dkrcp    /etc/hostname       container_UUID:

However, it fails with the message: "no such directory".

Since dkrcp ultimately relies on docker cp this defect will be addressed once docker cp has resolved Docker issue#20926

Until resolved, specify '/' to circumvent this problem:

dkrcp    /etc/hostname       container_UUID:/

--ucpchk-reg Provide ability to independently consider remote images

--ucpchk-reg currently enables searching remote registries for image names that are unknown to the local Docker Engine instance. However, since its implemented as a simple boolean, it simultaneously enables this behavior for both SOURCE and TARGET arguments. This issue requests enhancing the allowable values for --ucpchk-reg to permit independent expression of this feature.

TARGET file permission always reflect UID:0 GID:0

Currently, docker cp sets target image/container file permissions to 'root'. Perhaps a future version will accept specifying UID/GID.

-L, --follow-link option fails to dereference symbolic link

Although supported for Docker Engine 1.10+, this docker cp option doesn't seem to function. Therefore, its functionality doesn't currently work in dkrcp nor has it been tested. See docker cp issue #21146.