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

Peter Dalgaard pd.mes at cbs.dk
Wed Jan 17 11:52:11 CET 2018

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.


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

More information about the R-devel mailing list