Hi Jiefei,
the change in handling trailing path separators is not on purpose, but
is a byproduct of a new implementation of normalizePath, which now
handles symbolic links and normalizes case in long path names. It is not
documented what happens to trailing separators, and hence portable
programs should not depend on it. I don't think it is a property that
should be documented/specified. The behavior of normalizePath is way too
complicated already and it's result is OS-specific anyway.
In R-devel as well as in 3.6, the trailing separator is preserved when
the path does not exist - simply, the original path is returned. When
the path does exist, R-devel removes the trailing separator but R 3.6
does not, which is because the underlying Windows API call to implement
it is now different. The new behavior reflects what
GetFinalPathNameByHandle returns, which is a function now used for
normalization also in other language runtimes on Windows. I think the
new behavior is better: paths differing only in the trailing separator
will be normalized to the same path.
Best
Tomas
On 3/23/20 4:39 PM, Wang Jiefei wrote:
Hi all,
I saw a quite surprising result in the devel R when using the function
*normalizePath*. If the input is a path to a folder, the function returns
an absolute path with/without a slash at the end depending on the
of the folder. I know both results are valid on Windows but this behavior
is different than R3.6, I do not know if the change in the devel version
made on purpose. Here is a minimal example, suppose that the folder
`C:/windows1/` does not exist.
> normalizePath("C:/windows/", mustWork = FALSE)
normalizePath("C:/windows1/", mustWork = FALSE)
[1] "C:\\windows1\\"
In R 3.6, the return value always ends with a slash if the input ends
a slash. From the NEWS file, It seems like there are some changes to
*normalizePath* but none of them should be relevant, it might be an
unintentional result introduced by the update.
Best,
Jiefei
[[alternative HTML version deleted]]