Bug 1267357 - Dockerfile VOLUME instruction masks directory changes
Dockerfile VOLUME instruction masks directory changes
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker (Show other bugs)
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Antonio Murdaca
: Extras
Depends On:
  Show dependency treegraph
Reported: 2015-09-29 15:06 EDT by Chris Evich
Modified: 2015-10-29 11:59 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-10-29 11:59:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Dockerfile that reproduces the problem (156 bytes, text/plain)
2015-09-29 15:06 EDT, Chris Evich
no flags Details

  None (edit)
Description Chris Evich 2015-09-29 15:06:59 EDT
Created attachment 1078452 [details]
Dockerfile that reproduces the problem

Description of problem:
Modifying a file in a directory AFTER using the VOLUME instruction causes all further changes to that directory to be ignored/not tracked.  Moving the VOLUME instruction after the changes works properly.  

Version-Release number of selected component (if applicable):
docker-1.7.1-115.el7.x86_64 (RHEL AH 7.1.5

How reproducible:

Steps to Reproduce:
1. Stick Dockerfile into an empty directory
2. docker build -t test context

Actual results:
cat: /root/foobar: No such file or directory

Expected results:

Additional info:
Expecting contents of directory referenced in VOLUME instruction, to be tracked just like any other file changes, irrespective of VOLUME instruction order.

e.g. move the VOLUME instruction one line down (below echo, above cat), rebuild and it will work as expected.
Comment 2 Antonio Murdaca 2015-10-29 10:12:18 EDT
Unfortunately this is how it's implemented in Docker. It's stated here https://docs.docker.com/reference/builder/#volume.
The content is not going to be modified because it's going to the volume and not the container fs. Volumes do not get committed to an image. And each new RUN is a new container with a new volume.

Note You need to log in before you can comment on or make changes to this bug.