Tests to show broken behavior when a symlink is named lib #372
Conversation
| @@ -41,6 +43,13 @@ final class GradleUtils { | |||
| File sourceRoot = new File("/$sourceBase", sourceRelative) | |||
| File targetRoot = new File("/$sourceBase", targetPath.substring(sourceBasePath.length())) | |||
| Path relativeTarget = sourceRoot.isDirectory() ? sourceRoot.toPath().relativize(targetRoot.toPath()) : sourceRoot.parentFile.toPath().relativize(targetRoot.toPath()) | |||
| println sourceBase | |||
There was a problem hiding this comment.
I just put these in here to dump some output in the test output
|
|
||
| class GradleUtilsIntegrationTest extends IntegrationSpec { | ||
|
|
||
| def 'verifySymlinkDirNested'() { |
There was a problem hiding this comment.
builds a structure like so :
source
├── sourceDir
│ └── subdir
│ └── text.txt
└── notlib -> sourceDir/subdir
| linkFile.asString() == 'sourceDir/subdir' | ||
| } | ||
|
|
||
| def 'verifySymlinkDirNestedWithLib'() { |
There was a problem hiding this comment.
builds a structure like so :
source
├── sourceDir
│ └── subdir
│ └── text.txt
└── lib -> sourceDir/subdir
| @@ -41,6 +43,13 @@ final class GradleUtils { | |||
| File sourceRoot = new File("/$sourceBase", sourceRelative) | |||
| File targetRoot = new File("/$sourceBase", targetPath.substring(sourceBasePath.length())) | |||
| Path relativeTarget = sourceRoot.isDirectory() ? sourceRoot.toPath().relativize(targetRoot.toPath()) : sourceRoot.parentFile.toPath().relativize(targetRoot.toPath()) | |||
There was a problem hiding this comment.
Interestingly enough, if I just take the fork out of this line and leave the following all tests pass
Path relativeTarget = sourceRoot.parentFile.toPath().relativize(targetRoot.toPath())
It still doesn't answer why the link is being evaluated differently, but I don't ever see a use case for the first option here anyways. I'm probably missing something, but whenever this is successful, it evaluates false. Again, I believe that is correct since it is a link and isDirectory() should return false for that.
Even if we are at a "directory symlink", we would still want the relative path to the target from the parent I believe. Otherwise the path you get is going up out of the "link directory" and back down to the target. Like ../path/to/target. Then the link is broken.
These two tests are exactly the same expect one has a symlink named
liband the other isnotlib(notlibcan be anything and it works). The symlink namedlibfails as it does not recognizes the file as a directory, but it is not since it is a link. It needs the relative path of the parent.The link that is generated when the link is named
libhas an extra../prefixed to it which makes it invalid.I don't understand why the name of the link would make a difference here. Do you have any insight?