R devel - Mar 2020 - Inconsistant result for normalizePath on Windows

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]]

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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

Re the trailing path separator - should file.path() be changed to not
produce doubled path separators when an argument has a trailing path
separator?

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Mon, Mar 23, 2020 at 9:24 AM Tomas Kalibera <tomas.kalibera at
gmail.com>
wrote:
>
> 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 at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
	[[alternative HTML version deleted]]