From the documentation for toRealPath
:
The precise definition of this method is implementation dependent but in general it derives from this path, an absolute path that locates the same file as this path, but with name elements that represent the actual name of the directories and the file. For example, where filename comparisons on a file system are case insensitive then the name elements represent the names in their actual case. Additionally, the resulting path has redundant name elements removed.
If this path is relative then its absolute path is first obtained, as if by invoking the toAbsolutePath method.
The options array may be used to indicate how symbolic links are handled. By default, symbolic links are resolved to their final target. If the option NOFOLLOW_LINKS is present then this method does not resolve symbolic links. Some implementations allow special names such as ".." to refer to the parent directory. When deriving the real path, and a ".." (or equivalent) is preceded by a non-".." name then an implementation will typically cause both names to be removed. When not resolving symbolic links and the preceding name is a symbolic link then the names are only removed if it guaranteed that the resulting path will locate the same file as this path.
So that tells us a few things about toRealPath
:
- On a case-insensitive file system, if the actual path contains the name
Example
and the path string you're using contains example
instead, toRealPath
will give you Example
— the real name — instead of example
.
- Redundant parts of the path are removed.
- On a file system with symbolic links, if you don't specify the
NOFOLLOW_LINKS
option, symbolic links will be followed and the real path (without links) will be returned.
Contrast with toAbsolutePath
, which just resolves a relative path without necessarily doing that kind of additional processing.
In both cases, though, a fair bit of what they do is described as implementation-dependent.