[Rd] Inconsistant result for normalizePath on Windows

[Tomas Kalibera]

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 existence
> 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 is
> made on purpose. Here is a minimal example, suppose that the folder
> `C:/windows1/` does not exist.
>
>    > normalizePath("C:/windows/", mustWork = FALSE)
> [1] "C:\\Windows"
>> normalizePath("C:/windows1/", mustWork = FALSE)
> [1] "C:\\windows1\\"
>
>
> In R 3.6, the return value always ends with a slash if the input ends with
> 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]]
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel