Executed the following Docker V1.8 command:
docker cp ./hello.txt <containerUUID>:/mydir/hi.txt
File “hello.txt” exists in current host directory.
Directory “/mydir” does not exist in container.
Received following message from docker cp:
Error response from daemon: lstat /var/lib/docker/vfs/dir/<containerUUID>/mydir: no such file or directory
Although I would expect this behavior for the linux cp command, the Docker documentation implies that docker cp should create the destination directory in the container. Here's the relevant behavioral description extracted from the docker cp documentation:
Assuming
a path separator of /
,
a first argument of SRC_PATH
and second argument of DST_PATH
,
the behavior is as follows:
SRC_PATH
specifies a file
DST_PATH
does not exist
the
file is saved to a file created at DST_PATH
The
above verbiage “the
file is saved to a file created at DST_PATH”
given the context: “DST_PATH does not exist” implies the creation
of the destination directory file path
when
creating the file
.
Since
docker cp acts like linux cp by failing to create the directory
portion of DST_PATH, I'll assume
that the documentation
excerpt
above suggests
behavior beyond what was intended. Instead the described semantics
of docker cp should, in this context, treat DST_PATH as
either
a base name devoid of directory references
or
a file path where all directory elements must exist.
If
the assumption above correctly describes the desired intent, perhaps
the original
document
excerpt
should be replaced with the following:
SRC_PATH
specifies a file
DST_PATH
does not exist and specifies only a base name
the
file is saved to a file named DST_PATH
DST_PATH
does not exist
and
all directory references exist
the
file is saved to
the
file
created
at
DST_PATH
DST_PATH
does not exist
and
includes at least one nonexistent directory reference
Error
condition all directory references specified by DST_PATH must
exist
To
summarize, I'd appreciate feedback
concerning:
Is
docker cp designed to mimic linux cp failure mode when the SRC_PATH
specifies only a file and DST_PATH includes at least one nonexistent
directory reference?
If
docker cp intentionally mirrors the linux cp failure mode above,
should the website documentation be altered to more clearly state
docker cp's intended design?
If
documentation requires improvement, does the proposed alternate
concisely provide the necessary clarity?
Thanks!