r10k will delete files in an environment pointed to by a symlink

r10k decides what to purge by comparing all the files in an environment directory against a list of desired files, and purging anything not in that list of desired files. When you have a symlink in the control repo pointing to other files in the repo, some files show up twice when scanning the dir contents, once in their actual location, and again in their symlinked location.

So if you had the following in an environment:

=> ls -la spec/fixtures

total 0

drwxr-xr-x  3 aileen  staff  96 Oct 12 12:26 .

drwxr-xr-x  3 aileen  staff  96 Oct  8 15:49 ..

lrwxr-xr-x  1 aileen  staff  11 Oct 12 11:44 hieradata -> ../../hiera

=> ls -la hiera/data

total 8

drwxr-xr-x  3 aileen  staff  96 Oct 12 12:13 .

drwxr-xr-x  3 aileen  staff  96 Oct  8 15:51 ..

-rw-r--r--  1 aileen  staff  15 Oct  8 15:48 foo.yaml

The "total" list of files in the dir that r10k comes up with would include both hiera/data/foo.yaml and spec/fixtures/hieradata/data/foo.yaml, which are the same file. r10k marks the first path for keeping, but but not the second, because we're inconsistently following symlinks. This causes the actual file to be cleaned up, because its symlinked path was marked for purging.

Desired behavior:

• It should consider both paths as "desired" if both the source files and the symlink are desired.
• If the symlink is not desired, it should delete the link but not the files pointed to.
• If the symlink is desired but what it points to is not, I think it's okay to leave the link dangling. This seems like an edge case.