For docker-v1.10+ the directory layout isn't important anymore as all the paths are listed in manifest. We keep this structure because in tars from docker are compatible with both v1.0 and v1.1 specs. When we remove support for v1.0 we will probably also simplify this directory structure.

@tonistiigi as an aside, when do you think that will be? That is an important integration point for many.
Or rather, if we can evolve this into a common standard (read as OpenContainers) then would it need a --format=oci.v1 like integration?

I don't know. There is no problem with supporting both atm but we don't want to promote the old one because we can't have ID stability with the old version. id/json is the 1.0 image configuration with the parent chain and we don't use this method any more since v1.10.

understood

On Wed, Apr 27, 2016 at 2:26 PM Tõnis Tiigi notifications@github.com
wrote:

In image/spec/v1.1.md
#22264 (comment):

+.
+├── 47bcc53f74dc94b1920f0b34f6036096526296767650f223433fe65c35f149eb.json
+├── 5f29f704785248ddb9d06b90a11b5ea36c534865e9035e4022bb2e71d4ecbb9a
+│ ├── VERSION
+│ ├── json
+│ └── layer.tar
+├── a65da33792c5187473faa80fa3e1b975acba06712852d1dea860692ccddf3198
+│ ├── VERSION
+│ ├── json
+│ └── layer.tar
+├── manifest.json
+└── repositories
+```
+
+There are one or more directories named with the ChainID for each layer in a
+full image. Each of these directories contains 3 files:

I don't know. There is no problem with supporting both atm but we don't
want to promote the old one because we can't have ID stability with the old
version. id/json is the 1.0 image configuration with the parent chain and
we don't use this method any more since v1.10.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/22264/files/2801c4c22c04396ec912760a955752cd8955e841#r61310686

Should mention this file is also only used for backwards compatibility. Also at the end when discussing what "older implementations" will use.

Added a mention below.

any comment on the consistency of the mtime of these objects? That was a common important ask from folks in the community for consistency of docker save output (regardless that the checksum of the objects themselves being consistent)

I don't think we currently make any efforts to make mtimes consistent, or do anything else to support stable hashes of the save artifacts we generate.

There was a decent conversation around this and I had written the code for
it. So it was a thing. The json and layer.tar were given an mtime of the
layer creation time, and repositories was Unix epoch of 0
It is nicely consistent. :-)

On Thu, May 12, 2016, 12:52 Aaron Lehmann notifications@github.com wrote:

In image/spec/v1.1.md
#22264 (comment):

• - all tar archives of each layer filesystem changesets
  +
  +For example, here's what the full archive of library/busybox is (displayed in
  +tree format):
  +
  +```
  +.
  +├── 47bcc53f74dc94b1920f0b34f6036096526296767650f223433fe65c35f149eb.json
  +├── 5f29f704785248ddb9d06b90a11b5ea36c534865e9035e4022bb2e71d4ecbb9a
  +│ ├── VERSION
  +│ ├── json
  +│ └── layer.tar
  +├── a65da33792c5187473faa80fa3e1b975acba06712852d1dea860692ccddf3198
  +│ ├── VERSION
  +│ ├── json
  +│ └── layer.tar

I don't think we currently make any efforts to make mtimes consistent, or
do anything else to support stable hashes of the save artifacts we generate.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/22264/files/a07dd240ac7148093987380edc10222e63ba19e2#r63055557

@vbatts @aaronlehmann Yes, we still do the modified time reset like @vbatts described.

Could this sentence get added opencontainers/image-spec@949ea01

It applies to the docker behaviour as well.

That isn't quite correct. Volume is replaced but there is a copy operation that copies files from image to the volume. So the data from the image rootfs is still present.

oh no. This sounds like a "clever" use-case, but would allow for sneaky bugs. :-\

@tonistiigi just checking on this, and i'm not seeing that to be the case. Perhaps you can provide an example of what you're seeing with host files of a volume path being copied up?

@tonistiigi fair, but docker run -it -v /usr:/foo:ro foo ls /foo/ does not reveal /foo/bar

Yes, but docker run -it -v /usr:/foo:ro foo ls /foo/ doesn't have much to do with Volumes struct in the image configuration. Bind mounts just override everything and this behavior is independent of the image config.

this file is not explicitly referenced below

It is referenced in the example manifest.json below.

The directory name is not the ChainID. It is just a deterministic random hex. I think ChainID should just be an implementation detail, we probably don't need to define it at all here.

@tonistiigi: Fixed.