[Rd] loading library from network share (PR#8982)

Tony Plate tplate at acm.org
Thu Jun 22 22:19:54 CEST 2006

I had thought that one needed to be careful using mapped network drive 
letters to access network shares under MS Windows -- the current mapping 
for drive letters can depend on who is current logged in.   For 
non-critical interactive sessions there should be no problems with using 
mapped network drive letters -- the dangerous scenario is running 
scheduled tasks on a server.

Microsoft XP docs say:
     Connecting to network drives

     Do not use a redirected drive for scheduled jobs
     that access the network. The Schedule service
     might not be able to access the redirected drive,
     or the redirected drive might not be present if a
     different user is logged on at the time the
     scheduled task runs. Instead, use UNC paths for
     scheduled jobs. For example:

     at 1:00pm my_backup \\server\share

     Do not use the following syntax, where x: is a
     connection made by the user:

     at 1:00pm my_backup x:

(this is from the documentation for the "At" command, 

In addition to Prof Ripley's suggestion of setting up drive mapping 
using domain controllers, another workaround might be doing something 
like "net use x: \\server\share" in a scheduled task script.

-- Tony Plate

Prof Brian Ripley wrote:
> On Wed, 21 Jun 2006, roy_kuraisa at merck.com wrote:
>>Thanks for the info.
>>It's interesting that R can load the library using a network share naming
>>convention but that the library path has the "\" replaced with "/".  I guess
>>it's too much to ask for R not to muck with the file name provided (for a
>>variety of reasons).  My package works fine except for knowing the correct
>>library path.
>>As for mapping a drive, that's not a good solution for us because it would
>>require users to always create a specific map drive (which on their desktop
>>may not be available; when we add packages to other network shares, requires
>>additional maps; etc).  Overall, it's not a very flexible solution for us.
> It can easily be done via the domain controller: my sysadmins do it.
>>My work around which, at least in my unique case, is a bit more flexible
>>(but a little more klunky) is to add code in .First.lib that substitutes
>>"\\" for "//" (because I need to read a cfg file in the "data" folder of the
>>package when it is loaded).
> This should work now that I have changed dirname (to do precisely that), 
> but as I have no suitable test examples I cannot be sure.
>>cheers, roy
>>-----Original Message-----
>>From: Prof Brian Ripley [mailto:ripley at stats.ox.ac.uk]
>>Sent: Wednesday, June 21, 2006 1:57 AM
>>To: Kuraisa, Roy J (Rosetta)
>>Cc: R-bugs at biostat.ku.dk
>>Subject: Re: [Rd] loading library from network share (PR#8982)
>>This is not supported: network shares are a Windows 'feature' and not part
>>of R's conception of file paths.  The specific issue here is dirname(),
>>but it is widespread.
>>You can always map shares to network drives, and that is common practice
>>everywhere I have been which has extensive Windows networks.
>>We have changed the dirname case, but have no intention of supporting this
>>sort of file path in general, as one of the design goals of the Windows
>>port of R was to work as similarly to the Unix-alikes as possible (and to
>>share as much code as possible).
>>On Wed, 14 Jun 2006, roy_kuraisa at merck.com wrote:
>>>Full_Name: roy kuraisa
>>>Version: 2.2.1
>>>OS: Windows XP SP2
>>>Submission from: (NULL) (
>>>When loading a library from network share drive (e.g., \\nnn\f1\f2\p1),
>>>First.lib is called, the libray name contains "/" instead of "\" resulting
>>in an
>>>invalid Windows filepath.
>>>Here's an example:
>>>>From R,
>>>Within First.lib,
>>>.First.lib <-function(lib, pkg)
>>>   cat("lib name ",lib,"\n")
>>>produces the output
>>>  lib name //kodak/research_genetics/rlibs
>>>R-devel at r-project.org mailing list

More information about the R-devel mailing list