-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate replacing File.getCanonicalPath
with Path.getRealPath()
#2419
Comments
I just wanted to add that the current path handling code in Ceylon jumps numerous times back and forth between File and String while working with paths. This is exactly the use case that Path was created for. You will find If you want to add the ability to resolve
i.e. the recommended way of handling |
I just realized my own project FastClasspathScanner has this same bug, where it resolved symlinks, and then tried to resolve paths relative to each other while expecting that the paths had not jumped to somewhere else in the file hierarchy. (Had to add NOFOLLOW_LINKS there.) |
Thanks for the inf Luke! |
I should add that you need to search the source for both "CanonicalPath" and "CanonicalFile" to find all the places that need to have symlink resolution removed. It was only about a dozen changes, last time I looked. Switching the source loader and the module loader APIs to use Path objects rather than String or File objects should help find a lot of the places in the code that could be switched to using Path (in order to remove the duplicated code for doing Path.resolve() and related operations, and to make path handling uniform). |
@lukehutch deprecated repository ;) |
See #2416 but in short @lukehutch mentioned:
"As an example of what could go wrong, imagine a project root at MyProject/source that has a symlink from MyProject/source/com/xyz/package to MyOtherProject/source/com/xyz/package. Calling getCanonicalPath() will cause the source links to be based in MyOtherProject, while the source root is still in MyProject (because the source root occurs above the symlink).
I think the right thing to do is to never follow symlinks when absolutizing paths. You still need to handle ".." etc.
The "One Right Way" to handle paths in JDK >= 1.7 is using Path, not File. I recently switched a bunch of my own code from File to Path, and it's significantly nicer, more robust, more portable and safer to do things the Path way.
In this case, I think what you want is Path.toRealPath(LinkOption.NOFOLLOW_LINKS)."
The text was updated successfully, but these errors were encountered: