Re: [Rd] [R-win] Bug 17159 - recursive dir.create() fails on windows shares due to permissions (MMaechler: Resending to R-windows@R-pr..)

[Peter Dalgaard]

I usually draw a complete blank if  I try to assist our IT department with such 
issues (we really need better documentation than the Admin manual for 
large-system installs by non-experts in R). 

However, it is my impression that there are also options involving environment 
variables and LFS naming. E.g., map the networked user directory to, say, a P: 
"drive" and make sure that the environment is set up to reflect this.

-pd

> On 16 Jan 2018, at 17:52 , Joris Meys  wrote:
> 
> Hi all,
> 
> I ran into this exact issue yesterday during the exam of statistical
> computing. Users can install packages in a user library that R tries to
> create automatically on the network drive of the student. But that doesn't
> happen as the unc path is not read correctly, leading to R attempting to
> create a local directory and being told it has no right to do so.
> 
> That is an older version of R though (3.3), but I'm wondering whether I
> would ask our IT department to just update R on all these computers to the
> latest version, or if we have to look for another solution.
> 
> Cheers
> Joris
> 
> On Mon, Jan 8, 2018 at 1:43 PM, Thompson, Pete 
> wrote:
> 
>> Hi, I’d like to ask about bug 17159:
>> 
>> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17159
>> 
>> I can confirm that I see exactly this bug when using dir.create on paths
>> of UNC form (\\server\share\xxx), with the recursive flag set. I’m seeing
>> this when attempting to use install.packages with such a path (which I know
>> isn’t supported, but would be great if it was!). I can see that a patch has
>> been suggested for the problem and from looking at the source code I
>> believe it’s a correct fix. Is there a possibility of getting this patch
>> included?
>> 
>> The existing logic for Windows recursive dir.create (platform.c lines
>> 2209-22203) appears to be:
>> - Skip over any \\share at the start of the directory name
>> - Loop while there are pieces of directory name left (i.e. we haven’t hit
>> the last \ character)
>>  = Find the next portion of the directory name (up to the next \
>> character)
>>  = Attempt to create the directory (unless it is of the form x: - i.e. a
>> drive name)
>>  = Ignore any ‘already exists’ errors, otherwise throw an error
>> 
>> This logic appears flawed in that it skips \\share which isn’t a valid
>> path format (according to https://msdn.microsoft.com/en-
>> us/library/windows/desktop/aa365247(v=vs.85).aspx ). Dredging my memory,
>> it’s possible that \\share was a supported format in very old versions of
>> Windows, but it’s been a long time since the UNC format came in. It’s also
>> possible that \\share is a valid format in some odd environments, but the
>> UNC format is far more widely used.
>> 
>> The patch suggested by Evan Cortens is simply to change the skip logic to
>> skip over \\server\share instead of \\share. This will certainly fix the
>> common use case of using UNC paths, but doesn’t attempt to deal with all
>> the more complex options in Microsoft’s documentation. I doubt many users
>> would ask for the complex cases, but the basic UNC format would be of wide
>> applicability.
>> 
>> Thanks
>> Pete Thompson
>> Director, Information Technology
>> Head of Spotfire Centre of Excellence
>> IQVIA
>> 
>> 
>> 
>> 
>> 
>> IMPORTANT - PLEASE READ: This electronic message, including its
>> attachments, is CONFIDENTIAL and may contain PROPRIETARY or LEGALLY
>> PRIVILEGED or PROTECTED information and is intended for the authorized
>> recipient of the sender. If you are not the intended recipient, you are
>> hereby notified that any use, disclosure, copying, or distribution of this
>> message or any of the information included in it is unauthorized and
>> strictly prohibited. If you have received this message in error, please
>> immediately notify the sender by reply e-mail and permanently delete this
>> message and its attachments, along with any copies thereof, from all
>> locations received (e.g., computer, mobile device, etc.). Thank you.
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 
> 
> 
> -- 
> Joris Meys
> Statistical consultant
> 
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
> 
> 
> ---
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
> 
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> ___
> R-windows mailing list
> r-wind...@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-windows

-- 

Re: [Rd] [R-win] Bug 17159 - recursive dir.create() fails on windows shares due to permissions (MMaechler: Resending to R-windows@R-pr..)

[Thompson, Pete]

That solution works fine for the use case where each user has a network based 
home directory and needs to run R from there, but doesn’t help with my 
situation. I need to be able to support arbitrary network based paths in 
arbitrary numbers – so mapping drives isn’t an option. I have found a 
workaround using symbolic links to the network share created within the 
temporary folder, but would much prefer that R support UNC paths – it seems a 
reasonably simple fix.

Cheers
Pete


On 17/01/2018, 10:52, "Peter Dalgaard"  wrote:

I usually draw a complete blank if  I try to assist our IT department with 
such issues (we really need better documentation than the Admin manual for 
large-system installs by non-experts in R).

However, it is my impression that there are also options involving 
environment variables and LFS naming. E.g., map the networked user directory 
to, say, a P: "drive" and make sure that the environment is set up to reflect 
this.

-pd

> On 16 Jan 2018, at 17:52 , Joris Meys  wrote:
>
> Hi all,
>
> I ran into this exact issue yesterday during the exam of statistical
> computing. Users can install packages in a user library that R tries to
> create automatically on the network drive of the student. But that doesn't
> happen as the unc path is not read correctly, leading to R attempting to
> create a local directory and being told it has no right to do so.
>
> That is an older version of R though (3.3), but I'm wondering whether I
> would ask our IT department to just update R on all these computers to the
> latest version, or if we have to look for another solution.
>
> Cheers
> Joris
>
> On Mon, Jan 8, 2018 at 1:43 PM, Thompson, Pete 
> wrote:
>
>> Hi, I’d like to ask about bug 17159:
>>
>> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17159
>>
>> I can confirm that I see exactly this bug when using dir.create on paths
>> of UNC form (\\server\share\xxx), with the recursive flag set. I’m seeing
>> this when attempting to use install.packages with such a path (which I 
know
>> isn’t supported, but would be great if it was!). I can see that a patch 
has
>> been suggested for the problem and from looking at the source code I
>> believe it’s a correct fix. Is there a possibility of getting this patch
>> included?
>>
>> The existing logic for Windows recursive dir.create (platform.c lines
>> 2209-22203) appears to be:
>> - Skip over any \\share at the start of the directory name
>> - Loop while there are pieces of directory name left (i.e. we haven’t hit
>> the last \ character)
>>  = Find the next portion of the directory name (up to the next \
>> character)
>>  = Attempt to create the directory (unless it is of the form x: - i.e. a
>> drive name)
>>  = Ignore any ‘already exists’ errors, otherwise throw an error
>>
>> This logic appears flawed in that it skips \\share which isn’t a valid
>> path format (according to https://msdn.microsoft.com/en-
>> us/library/windows/desktop/aa365247(v=vs.85).aspx ). Dredging my memory,
>> it’s possible that \\share was a supported format in very old versions of
>> Windows, but it’s been a long time since the UNC format came in. It’s 
also
>> possible that \\share is a valid format in some odd environments, but the
>> UNC format is far more widely used.
>>
>> The patch suggested by Evan Cortens is simply to change the skip logic to
>> skip over \\server\share instead of \\share. This will certainly fix the
>> common use case of using UNC paths, but doesn’t attempt to deal with all
>> the more complex options in Microsoft’s documentation. I doubt many users
>> would ask for the complex cases, but the basic UNC format would be of 
wide
>> applicability.
>>
>> Thanks
>> Pete Thompson
>> Director, Information Technology
>> Head of Spotfire Centre of Excellence
>> IQVIA
>>
>>
>>
>>
>> 
>> IMPORTANT - PLEASE READ: This electronic message, including its
>> attachments, is CONFIDENTIAL and may contain PROPRIETARY or LEGALLY
>> PRIVILEGED or PROTECTED information and is intended for the authorized
>> recipient of the sender. If you are not the intended recipient, you are
>> hereby notified that any use, disclosure, copying, or distribution of 
this
>> message or any of the information included in it is unauthorized and
>> strictly prohibited. If you have received this message in error, please
>> immediately notify the sender by reply e-mail and permanently delete this
>> message and its attachments, along with any copies thereof, from all
>> locations received (e.g., computer, mobile device, etc.). Thank you.
>> __
>> R-devel@r-project.org mailing list

Re: [Rd] [R-win] Bug 17159 - recursive dir.create() fails on windows shares due to permissions (MMaechler: Resending to R-windows@R-pr..)

[Peter Dalgaard]

I can easily believe that. It was maily for Joris, that it might not be 
necessary to reinstall. 

-pd

> On 17 Jan 2018, at 11:55 , Thompson, Pete  wrote:
> 
> That solution works fine for the use case where each user has a network based 
> home directory and needs to run R from there, but doesn’t help with my 
> situation. I need to be able to support arbitrary network based paths in 
> arbitrary numbers – so mapping drives isn’t an option. I have found a 
> workaround using symbolic links to the network share created within the 
> temporary folder, but would much prefer that R support UNC paths – it seems a 
> reasonably simple fix.
> 
> Cheers
> Pete
> 
> 
> On 17/01/2018, 10:52, "Peter Dalgaard"  wrote:
> 
>I usually draw a complete blank if  I try to assist our IT department with 
> such issues (we really need better documentation than the Admin manual for 
> large-system installs by non-experts in R).
> 
>However, it is my impression that there are also options involving 
> environment variables and LFS naming. E.g., map the networked user directory 
> to, say, a P: "drive" and make sure that the environment is set up to reflect 
> this.
> 
>-pd
> 
>> On 16 Jan 2018, at 17:52 , Joris Meys  wrote:
>> 
>> Hi all,
>> 
>> I ran into this exact issue yesterday during the exam of statistical
>> computing. Users can install packages in a user library that R tries to
>> create automatically on the network drive of the student. But that doesn't
>> happen as the unc path is not read correctly, leading to R attempting to
>> create a local directory and being told it has no right to do so.
>> 
>> That is an older version of R though (3.3), but I'm wondering whether I
>> would ask our IT department to just update R on all these computers to the
>> latest version, or if we have to look for another solution.
>> 
>> Cheers
>> Joris
>> 
>> On Mon, Jan 8, 2018 at 1:43 PM, Thompson, Pete 
>> wrote:
>> 
>>> Hi, I’d like to ask about bug 17159:
>>> 
>>> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17159
>>> 
>>> I can confirm that I see exactly this bug when using dir.create on paths
>>> of UNC form (\\server\share\xxx), with the recursive flag set. I’m seeing
>>> this when attempting to use install.packages with such a path (which I know
>>> isn’t supported, but would be great if it was!). I can see that a patch has
>>> been suggested for the problem and from looking at the source code I
>>> believe it’s a correct fix. Is there a possibility of getting this patch
>>> included?
>>> 
>>> The existing logic for Windows recursive dir.create (platform.c lines
>>> 2209-22203) appears to be:
>>> - Skip over any \\share at the start of the directory name
>>> - Loop while there are pieces of directory name left (i.e. we haven’t hit
>>> the last \ character)
>>> = Find the next portion of the directory name (up to the next \
>>> character)
>>> = Attempt to create the directory (unless it is of the form x: - i.e. a
>>> drive name)
>>> = Ignore any ‘already exists’ errors, otherwise throw an error
>>> 
>>> This logic appears flawed in that it skips \\share which isn’t a valid
>>> path format (according to https://msdn.microsoft.com/en-
>>> us/library/windows/desktop/aa365247(v=vs.85).aspx ). Dredging my memory,
>>> it’s possible that \\share was a supported format in very old versions of
>>> Windows, but it’s been a long time since the UNC format came in. It’s also
>>> possible that \\share is a valid format in some odd environments, but the
>>> UNC format is far more widely used.
>>> 
>>> The patch suggested by Evan Cortens is simply to change the skip logic to
>>> skip over \\server\share instead of \\share. This will certainly fix the
>>> common use case of using UNC paths, but doesn’t attempt to deal with all
>>> the more complex options in Microsoft’s documentation. I doubt many users
>>> would ask for the complex cases, but the basic UNC format would be of wide
>>> applicability.
>>> 
>>> Thanks
>>> Pete Thompson
>>> Director, Information Technology
>>> Head of Spotfire Centre of Excellence
>>> IQVIA
>>> 
>>> 
>>> 
>>> 
>>> 
>>> IMPORTANT - PLEASE READ: This electronic message, including its
>>> attachments, is CONFIDENTIAL and may contain PROPRIETARY or LEGALLY
>>> PRIVILEGED or PROTECTED information and is intended for the authorized
>>> recipient of the sender. If you are not the intended recipient, you are
>>> hereby notified that any use, disclosure, copying, or distribution of this
>>> message or any of the information included in it is unauthorized and
>>> strictly prohibited. If you have received this message in error, please
>>> immediately notify the sender by reply e-mail and permanently delete this
>>> message and its attachments, along with any copies thereof, from all
>>> locations received (e.g., computer, mobile device, etc.). Thank you.
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/

Re: [Rd] [R-win] Bug 17159 - recursive dir.create() fails on windows shares due to permissions (MMaechler: Resending to R-windows@R-pr..)

[Joris Meys]

Hi Peter,

I share your experience with trying to help IT departments setting things
up. The network directory of the students is mapped to a drive, but R still
uses the unc path instead of the drive when attempting to create that user
library. Unless I do it manually of course. The only solution I see right
now is to set the HOME or R_LIBS_USER environment variable in Renviron, but
that should be done each time a new student logs into the computer. Or is
there a way to ensure R uses the mapped drive instead of the network unc
path, either using an R setting or by messing with Windows itself?

Cheers
Joris



On Wed, Jan 17, 2018 at 1:21 PM, Peter Dalgaard  wrote:

> I can easily believe that. It was maily for Joris, that it might not be
> necessary to reinstall.
>
> -pd
>
> > On 17 Jan 2018, at 11:55 , Thompson, Pete 
> wrote:
> >
> > That solution works fine for the use case where each user has a network
> based home directory and needs to run R from there, but doesn’t help with
> my situation. I need to be able to support arbitrary network based paths in
> arbitrary numbers – so mapping drives isn’t an option. I have found a
> workaround using symbolic links to the network share created within the
> temporary folder, but would much prefer that R support UNC paths – it seems
> a reasonably simple fix.
> >
> > Cheers
> > Pete
> >
> >
> > On 17/01/2018, 10:52, "Peter Dalgaard"  wrote:
> >
> >I usually draw a complete blank if  I try to assist our IT department
> with such issues (we really need better documentation than the Admin manual
> for large-system installs by non-experts in R).
> >
> >However, it is my impression that there are also options involving
> environment variables and LFS naming. E.g., map the networked user
> directory to, say, a P: "drive" and make sure that the environment is set
> up to reflect this.
> >
> >-pd
> >
> >> On 16 Jan 2018, at 17:52 , Joris Meys  wrote:
> >>
> >> Hi all,
> >>
> >> I ran into this exact issue yesterday during the exam of statistical
> >> computing. Users can install packages in a user library that R tries to
> >> create automatically on the network drive of the student. But that
> doesn't
> >> happen as the unc path is not read correctly, leading to R attempting to
> >> create a local directory and being told it has no right to do so.
> >>
> >> That is an older version of R though (3.3), but I'm wondering whether I
> >> would ask our IT department to just update R on all these computers to
> the
> >> latest version, or if we have to look for another solution.
> >>
> >> Cheers
> >> Joris
> >>
> >> On Mon, Jan 8, 2018 at 1:43 PM, Thompson, Pete  >
> >> wrote:
> >>
> >>> Hi, I’d like to ask about bug 17159:
> >>>
> >>> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17159
> >>>
> >>> I can confirm that I see exactly this bug when using dir.create on
> paths
> >>> of UNC form (\\server\share\xxx), with the recursive flag set. I’m
> seeing
> >>> this when attempting to use install.packages with such a path (which I
> know
> >>> isn’t supported, but would be great if it was!). I can see that a
> patch has
> >>> been suggested for the problem and from looking at the source code I
> >>> believe it’s a correct fix. Is there a possibility of getting this
> patch
> >>> included?
> >>>
> >>> The existing logic for Windows recursive dir.create (platform.c lines
> >>> 2209-22203) appears to be:
> >>> - Skip over any \\share at the start of the directory name
> >>> - Loop while there are pieces of directory name left (i.e. we haven’t
> hit
> >>> the last \ character)
> >>> = Find the next portion of the directory name (up to the next \
> >>> character)
> >>> = Attempt to create the directory (unless it is of the form x: - i.e. a
> >>> drive name)
> >>> = Ignore any ‘already exists’ errors, otherwise throw an error
> >>>
> >>> This logic appears flawed in that it skips \\share which isn’t a valid
> >>> path format (according to https://msdn.microsoft.com/en-
> >>> us/library/windows/desktop/aa365247(v=vs.85).aspx ). Dredging my
> memory,
> >>> it’s possible that \\share was a supported format in very old versions
> of
> >>> Windows, but it’s been a long time since the UNC format came in. It’s
> also
> >>> possible that \\share is a valid format in some odd environments, but
> the
> >>> UNC format is far more widely used.
> >>>
> >>> The patch suggested by Evan Cortens is simply to change the skip logic
> to
> >>> skip over \\server\share instead of \\share. This will certainly fix
> the
> >>> common use case of using UNC paths, but doesn’t attempt to deal with
> all
> >>> the more complex options in Microsoft’s documentation. I doubt many
> users
> >>> would ask for the complex cases, but the basic UNC format would be of
> wide
> >>> applicability.
> >>>
> >>> Thanks
> >>> Pete Thompson
> >>> Director, Information Technology
> >>> Head of Spotfire Centre of Excellence
> >>> IQVIA
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>> I