Inconsistant result for normalizePath on Windows

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Inconsistant result for normalizePath on Windows

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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistant result for normalizePath on Windows

R devel mailing list
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 <[hidden email]>
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]]
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel