If both symlinkFile and symlinkFileDup are passed to go-bindata, we would
still want both assets to be generated. The current implementation only
generates the first asset encountered, which is symlinkFile/file1.
That said, we still have a bug in which multiple symlinks in the same input
pointing to the same source won't be generated properly. Consider the
following case:
We would expect both file1 and file2 to be generated, but that is not the
case. Fixing this requires a much more thorough approach as the current
implementation does not support that easily. For now, we could generate those
two files by passing both file1 and file2 as separate inputs.
Symlinks implementation was added in https://github.com/kevinburke/go-bindata/commit/465fc29db9b716ec2ac11b1125939d383c143845. However, that did not account for the fact that multiple symlinks can point to the same source. When that happens, we would still want assets to be generated accordingly.
This commit fixes missing assets due to symlinks pointing to the same source in different inputs. Consider the following example:
symlinkFile └── file1 -> ../symlinkSrc/file1 symlinkFileDup └── file1 -> ../symlinkSrc/file1 symlinkSrc └── file1
If both symlinkFile and symlinkFileDup are passed to go-bindata, we would still want both assets to be generated. The current implementation only generates the first asset encountered, which is symlinkFile/file1.
That said, we still have a bug in which multiple symlinks in the same input pointing to the same source won't be generated properly. Consider the following case:
├── file1 -> ../symlinkSrc/file1 └── file2 -> ../symlinkSrc/file1
We would expect both file1 and file2 to be generated, but that is not the case. Fixing this requires a much more thorough approach as the current implementation does not support that easily. For now, we could generate those two files by passing both file1 and file2 as separate inputs.
cc: @kevinburke