R devel - Jan 2018 - Bug 17159 - recursive dir.create() fails on windows shares due to permissions

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.

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 <Pete.Thompson at
iqvia.com>
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 at 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)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>

-----------
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

	[[alternative HTML version deleted]]

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 <jorismeys at gmail.com> 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 <Pete.Thompson at
iqvia.com>
> 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 at 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)
>
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
> 
> -----------
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
> 
> -------------------------------
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> _______________________________________________
> R-windows mailing list
> R-windows at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-windows
-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com