docker-osx-dev icon indicating copy to clipboard operation
docker-osx-dev copied to clipboard

Symlinks cause confusing behaviour

Open JKrag opened this issue 9 years ago • 2 comments

I noticed the hard way, while testing the case-sensitivity issue, that the tool handles symlinked folders somewhat unexpectedly. For testing purposes, I put my work folder under /tmp/... without noticing that /tmp is symlinked to /private /tmp. fswatch or rsync "silently" translates the paths to the full system path (/private/tmp/...) and syncs these to /private/tmp/... inside the boot2docker. This is as such not a problem, except that if I am locally at /tmp, then: docker run -v $(pwd):/data .... fails to find the files as /tmp is not a symlink to /private/tmp inside the boot2docker.

I don't know just yet what behaviour I would prefer, so maybe just a warning in the docs for now?

JKrag avatar May 29 '15 15:05 JKrag

Yea, you're right. I'm using greadlink to convert paths to absolute paths, but that also resolves symlinks.

I'm not sure on the best solution, but am open to ideas.

brikis98 avatar May 29 '15 18:05 brikis98

I haven't thought this through in detail, but for the sake of discussion, we should look at two separate questions. a) What is the best behaviour regarding paths outside of the synced folder, i.e. pwd. Based solely on my own current use case, I would prefer that my actual current path (= pwd) is the one that is reflected into boot2docker, so that in the normal case where I run docker-osx-dev in my current project, then docker -v $(pwd):.... actually works as expected, which I guess is the whole point in mapping the folders 1-to-1 with absolute path inside the b2d.

b) What is the best behaviour with regards to the files actually synced into b2d? In this case, my first gut feeling would be to preserve everything as close as possible to what it really is locally, as this provides the best testing and flexibility. But as far as I can see, this is already the behaviour you chose using rsync --archive, which implicitly includes -l (i.e. preserve symlinks as symlinks).

Hope this makes at least some sense.

As said, I haven't thought it through in detail, so there might be very valid reasons to keep the existing behaviour for a) as well.

JKrag avatar May 29 '15 20:05 JKrag