convert: fix missing assets due to symlinks pointing to the same source in different inputs #34
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
in different inputs Symlinks implementation was added in kevinburke@465fc29. 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*. Signed-off-by: Jay Lim <[email protected]>
imjching
force-pushed
the
multiple-similar-symlinks
branch
from
979ead8 to
e79f7cb
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Symlinks implementation was added in 465fc29.
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