[pkg/archive] Update archive/copy path handling
- Remove unused TarOptions.Name field.
- Add new TarOptions.RebaseNames field.
- Update some of the logic around path dir/base splitting.
- Update some of the logic behind archive entry name rebasing.
[api/types] Add LinkTarget field to PathStat
[daemon] Fix stat, archive, extract of symlinks
These operations *should* resolve symlinks that are in the path but if the
resource itself is a symlink then it *should not* be resolved. This patch
puts this logic into a common function `resolvePath` which resolves symlinks
of the path's dir in scope of the container rootfs but does not resolve the
final element of the path. Now archive, extract, and stat operations will
return symlinks if the path is indeed a symlink.
[api/client] Update cp path hanling
[docs/reference/api] Update description of stat
Add the linkTarget field to the header of the archive endpoint.
Remove path field.
[integration-cli] Fix/Add cp symlink test cases
Copying a symlink should do just that: copy the symlink NOT
copy the target of the symlink. Also, the resulting file from
the copy should have the name of the symlink NOT the name of
the target file.
Copying to a symlink should copy to the symlink target and not
modify the symlink itself.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
* Add space between values in docker stats output for easier parsing
Old output could not be parsed easily because there were columns
that did not have any separator. Also values that are together
without any space is difficult to read even for humans.
* Update unit.HumanSize comment to match what the does actually does
Signed-off-by: Otto Kekäläinen <otto@seravo.fi>
Options for zfs storage driver were incorrectly placed
under 'exec driver options' header. Move the header to
the correct place.
Now, this is the second time I am fixing this. First time
it was commit 68efb27, but the following commit 9af7afb
screwed it up again, so the header appears twice now.
Get rid of the the wrong one.
Cc: David Calavera <david.calavera@gmail.com>
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
- boot2docker is deprecated in the 1.8.0
- docker-machine replaces it
- this fixes#14563
- Updating with thaJetzah comments
Signed-off-by: Mary Anthony <mary@docker.com>
PR #11907 added support for import using file (path), but it missed
the update of cli/import.md. This fixes that.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Update help line to allow 90 characters instead of 80
The trust flag pushes out the help description column wider, requiring more room to display help messages.
Signed-off-by: Derek McGowan <derek@mcgstyle.net> (github: dmcgowan)
* Clarify the list of supported instructions.
* Clarify behavior of ONBUILD, based on comments by @SvenDowideit, @theJeztah in PR #14735.
* Reorder list of instructions in alphabetical order.
Signed-off-by: Charles Chan <charleswhchan@users.noreply.github.com>
Based on the list containers with filters options it would seem that filtering containers with label `test=docker-java` could be done with `{"test":["docker-java"]}` which doesn't work
The options that work are `{"label":["test"]}` and `{"label":["test=docker-java"]}`
As seen in https://github.com/docker-java/docker-java/pull/262
Signed-off-by: Carlos Sanchez <carlos@apache.org>
Re-add the docs from @calavera's PR to the moved cli cmd reference docs.
Fix gofmt and vet issues from carried commits
Add integration test for using format with --no-trunc and multi-names
Fix custom_test map order dependency on expected value check
Add docs to reference/commandline/ps.md
Remove "-F" flag option from original carried PR content
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Documented changes to API to enable new `docker cp` behavior.
Added documentation on `docker cp` usage and behavior.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
As suggested in https://github.com/docker/docker/pull/14004/files#r34022527
The concern there is we can't differentiate whether user explicitly
asked for an invalid value of -1 or he did not specify anything.
I don't think this would be a problem, because:
- like all other default values like zero, we can't differentiate
user specify it or not, most of which, zeros are also invalid, so
default is default, we show these default values in help info,
so users would know if they set value as default, it'll be like
they set nothing.
- we can't do this kind of string check in REST api request, so
it'll make the behave different from docker command and RESTapi.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
