Investigate replacing `File.getCanonicalPath` with `Path.getRealPath()` about ceylon-compiler HOT 5 OPEN

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 basePath.resolve(relativeOrAbsolutePath) useful too, it does a lot of work that is re-implemented in several places in the Ceylon code.

If you want to add the ability to resolve file:// URLs as paths, you need to do some trickier things to get correct Windows support while handling possibly-broken mixes of file:// URLs and system-dependent path formats. The correct recipe is:

basePath.resolve(Paths.get(new URL(pathStr).toURI())).toRealPath(LinkOption.NOFOLLOW_LINKS)

i.e. the recommended way of handling file:// URLs is to convert from URL -> URI -> Path. (Reference 1) ; (Reference 2)

from ceylon-compiler.

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.)

from ceylon-compiler.

Thanks for the inf Luke!

from ceylon-compiler.

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).

from ceylon-compiler.

@lukehutch deprecated repository ;)

from ceylon-compiler.