[R] UNC Windows path beginning with backslashes

Henrik Bengtsson hb at biostat.ucsf.edu
Thu Aug 18 19:31:58 CEST 2011 

I think you can also do this from within R (e.g. in your .Rprofile)
using the R.utils package;

library("R.utils")
System$mapDriveOnWindows("K", "\\\\campden\\shares\\Workgroup\\Stats")
driveLetters <- System$getMappedDrivesOnWindows()
System$unmapDriveOnWindows("K")

These methods utilize 'subst' of MS Windows.

/Henrik

On Thu, Aug 18, 2011 at 6:12 PM, Keith Jewell <k.jewell at campden.co.uk> wrote:
> Just to close this off, in case it helps anyone else in a similar
> situation...
>
> Background: I have R installed on a UNC share with a site library named by
> major and minor version, thus:
> \\campden\shares\Workgroup\Stats 'root'
> \\campden\shares\Workgroup\Stats\R  base for R related things
> \\campden\shares\Workgroup\Stats\R\R-2.13.1 one R installation
> \\campden\shares\Workgroup\Stats\R\library site libraries go here
> \\campden\shares\Workgroup\Stats\R\library\2.13 site library for R 2.13.x
>
> I took the hint and mapped a drive from which to start R.
> Because I don't have a pre-determined drive letter to use I wrote a little
> .bat file to do the job:
> ------------------
> REM find or 'net use' a drive mapped to stats share
> set remote=\\campden\shares\Workgroup\Stats
> set drive=
> :check
> for /f "delims=*" %%a in ('net use ^| find "%remote%"') do set drive=%%a
> if not defined drive net use * %remote% /persistent:NO>nul & goto check
> set StatsDrive=%drive:~13,2%
> REM using that drive
> REM a) ensure GTK+ is in the path (for packages such as 'playwith')
> REM b) start 32 bit R
> set path=%StatsDrive%/R/GTK+/bin;%path%
> start %StatsDrive%\R\R-2.13.1\bin\i386\Rgui.exe
> ----------------------------------------
> That's a bit flakey, depending on the exact format of the output from 'net
> use'. If anyone has a better solution, I'll appreciate it!
>
> Now the site library:
> Putting a UNC path into Renviron.site thus...
>  R_LIBS_SITE=//campden/shares/workgroup/stats/R/library/%v
> ... was the cause of my original problem.
> I can't put it in as a mapped drive, because I don't know the drive until
> run time.
> I tried to work up and down from the drive mapped R_HOME...
>  R_LIBS_SITE=${R_HOME}/.../library/%v
> ... but that didn't work in Renviron.site.
>> Sys.getenv("R_HOME")
> [1] "Z:/R/R-2.13.1"
> ... which is fine, but...
>> Sys.getenv("R_LIBS_SITE")
> [1] "Z:RR-2.13.1/.../library/2.13"
> I think this may be something to do with this quote from ?Startup...
> "value is then processed in a similar way to a Unix shell: in particular the
> outermost level of (single or double) quotes is stripped, and backslashes
> are removed except inside quotes"
> ...but I don't have any control over R_HOME, specifically how and when
> forward- or back-slashes are used or removed.
>
> In the end I used Renviron.site just to pass the version information...
>   R_Libs_Site=%v
> That directory doesn't exist so doesn't get added to .libPaths()
> In Rprofile.site I worked up and down from R_HOME...
>  .libPaths(file.path(dirname(R.home()),"library",Sys.getenv("R_Libs_Site")))
> ... which seems to do the job.
>
> It isn't pretty, and the .bat file will probably need changing in future
> versions of Windows.
> But by the time R has started there isn't a UNC path in sight.
> I still think I've probably re-invented a wheel and ended up with something
> square, but it is going round.
>
> Best regards,
>
> Keith Jewell
>
> "Keith Jewell" <k.jewell at campden.co.uk> wrote in message
> news:j22q11$9u9$1 at dough.gmane.org...
>> Thanks Uwe.
>>
>> I'm aware (and have been forcefully reminded) that using a mapped drive
>> avoids these problems. But there is no single drive letter which I can use
>> site-wide, so I have problems with things like R_LIBS_SITE. As I've
>> outlined I'm exploring a range of solutions, including mapping a drive
>> where I can.
>>
>> I posted in the hope of learning from and perhaps helping those with
>> similar problems. I hope that it is permissible to discuss non-canonical
>> use of R on this list, I certainly did not intend disrespect for the R
>> developers (or to make typing errors).
>>
>> Best regards
>>
>> Keith Jewell
>>
>> "Uwe Ligges" <ligges at statistik.tu-dortmund.de> wrote in message
>> news:4E44091E.7090309 at statistik.tu-dortmund.de...
>>> This is extremely tricky since Windows does not always accept "//" rather
>>> than "\\". Additionally, there is not implemented system call in Windows,
>>> hence ?Sys.glob tells us a "partial emulation" is provided and "An
>>> attempt is made to handle UNC paths starting with a double backslash."
>>>
>>> As you have seenm this does not work everywhere, therefore it is
>>> advisable to run R from mapped drives - as I am doing in the network of
>>> our university for 13 years without problems now.
>>>
>>> Best,
>>> Uwe Ligges
>>>
>>>
>>> On 11.08.2011 18:29, Keith Jewell wrote:
>>>> Hi,
>>>>
>>>> Back in June I posted the message below, but had no replies. I've made a
>>>> little progress since then so this is to update anyone interested (!)
>>>> and to
>>>> ask for comments.
>>>>
>>>> Brief problem statement:
>>>> Under Windows, some parts of R don't handle UNC paths beginning with
>>>> backslashes. Specifically
>>>> a) Sys.glob() fails to find some files breaking (e.g.) Rcmdr plugins
>>>>         Sys.glob(file.path(.libPaths(), "*/etc/menus.txt"))
>>>>     fails to find files which are there
>>>>
>>>> b) update.packages(ask='graphics') fails when copying the updates into
>>>> the
>>>> destination folders
>>>>
>>>> In Renviron.site I define the site library with forward slashes, not
>>>> backslashes thus...
>>>>     R_LIBS_SITE=//campden/shares/workgroup/stats/R/library/%v
>>>> ... but the startup process seems to replace them with forward slashes.
>>>> I guess because  .libPaths with a 'new' argument calls normalizePath
>>>> which
>>>> changes leading slashes to backslashes, even with winslash="/"
>>>>> normalizePath("//campden/shares/workgroup/stats/R/library",
>>>>> winslash="/")
>>>> [1] "\\\\campden/shares/workgroup/Stats/R/library"
>>>>
>>>> I've corrected (??) this by inserting a line into Rprofile.site
>>>>    assign(".lib.loc", gsub("\\", "/", .libPaths(), fixed=TRUE),
>>>> env=environment(.libPaths))
>>>> That seems to fix problem (a) above, which was affecting a number of
>>>> users.
>>>> But have I broken anything else?
>>>>
>>>> I'm still experiencing problem (b).
>>>> I'm the only person on site who updates packages so I've mapped a drive
>>>> letter (L:) and in my own .Rprofile I have a line
>>>>     assign(".lib.loc", sub("//campden/shares/workgroup/Stats", "L:",
>>>> .libPaths(), ignore.case = TRUE), env=environment(.libPaths))
>>>>
>>>> So that's OK as far as it goes, but it's all a bit messy!
>>>> If .libPaths is called with a 'new' argument it will breaks things
>>>> again.
>>>> normalizePath seems to produce paths that don't work with Sys.glob.
>>>>
>>>> I have the feeling I'm being silly and making hard work of all this.
>>>>
>>>> Any comments? Suggestions?
>>>>
>>>> Best regards, and thanks in advance/
>>>>
>>>> Keith Jewell
>>>>
>>>> "Keith Jewell"<k.jewell at campden.co.uk>  wrote in message news:...
>>>>> Hi,
>>>>>
>>>>> Back in 2010 I had a problem with 'update.packages()', which I worked
>>>>> around by mapping a drive letter to a UNC path [described in
>>>>> <http://finzi.psych.upenn.edu/Rhelp10/2010-February/229820.html>  but
>>>>> my
>>>>> current workaround is
>>>>> assign(".lib.loc", sub("\\\\\\\\Server02/stats", "L:", .libPaths(),
>>>>> ignore.case = TRUE), env=environment(.libPaths))].
>>>>>
>>>>> More recently a colleague had problems using the 'FactoMineR' plug in
>>>>> for
>>>>> the Rcmdr package;
>>>>> a) directly loading 'RcmdrPlugin.FactoMineR' opened and "crashed" R
>>>>> Commander;
>>>>> b) opening R Commander without FactoMiner, the Tools option 'Load Rcmdr
>>>>> plug-in(s)...' was greyed out.
>>>>>
>>>>> It transpired that in .libPaths() the path to the library holding
>>>>> 'RcmdrPlugin.FactoMineR' was specified as a UNC address:
>>>>> \\\\Server02/stats/R/library/2.13>. Mapping a virtual drive letter
>>>>> (e.g.
>>>>> L:) and specifying the path in .libPaths() as a 'local file system'
>>>>> (LFS)
>>>>> address<L:/R/library/2.13>  fixed the problem.
>>>>>
>>>>> I contacted Professor Fox (maintainer of Rcmdr) who told me that Rcmdr
>>>>> finds plug-in packages via the command
>>>>>   plugins<- unlist(lapply(.libPaths(), function(x)
>>>>> Sys.glob(file.path(x,
>>>>> "*/etc/menus.txt"))))
>>>>> Because file.path and Sys.glob are both vectorised I think (but am not
>>>>> certain) that this could be simplified to:
>>>>>   plugins<- Sys.glob(file.path(.libPaths(), "*/etc/menus.txt"))
>>>>> but that's by the way, the problem seems to lie in Sys.glob under
>>>>> Windows
>>>>> operating systems.
>>>>>
>>>>> I note that 'help(Sys.glob)' on my Windows system  differs from
>>>>> <http://finzi.psych.upenn.edu/R/library/base/html/Sys.glob.html>.
>>>>> The latter says "For precise details, see your system's documentation
>>>>> on
>>>>> the glob system call.  There is a POSIX 1003.2 standard<snip>  The rest
>>>>> of these details are indicative (and based on the POSIX standard)".
>>>>> On Windows "The glob system call is not part of Windows, and we supply
>>>>> a
>>>>> partial emulation.<snip>  An attempt is made to handle UNC paths
>>>>> starting
>>>>> with a double backslash" which doesn't really inspire confidence.
>>>>>
>>>>> This was discussed in a 2009 R-devel thread starting here
>>>>> <https://stat.ethz.ch/pipermail/r-devel/2009-June/053879.html>, but the
>>>>> patch proposed in that thread seems not to have been implemented (??).
>>>>>
>>>>> Trying to avoid Sys.glob in the Rcmdr application I came up with this:
>>>>>       list.files(path=file.path(list.files(path=.libPaths(),
>>>>> full.names=TRUE), "etc"), pattern="^menus\\.txt$", full.names=TRUE)
>>>>> It seems to give identical results to Sys.glob for mapped drives, works
>>>>> with UNC paths in Windows, and seems quite fast.
>>>>>
>>>>> So my questions relate to diagnosis, prognosis, and prescription
>>>>> (cure?).
>>>>>
>>>>> 1) Diagnosis: Am I correct that my problem(s) originate in the "partial
>>>>> emulation" of glob in Windows.
>>>>>
>>>>> 2) Prognosis: If so, is there any likelihood that the emulation will
>>>>> improve in the near future?
>>>>>
>>>>> 3) Prescription: If not:
>>>>>
>>>>> a) is assign(".lib.loc", sub("\\\\\\\\Server02/stats", "L:",
>>>>> .libPaths(),
>>>>> ignore.case = TRUE), env=environment(.libPaths))
>>>>> a reasonable workaround in a specific case?
>>>>>
>>>>> b) is list.files(path=file.path(list.files(path=.libPaths(),
>>>>> full.names=TRUE), "etc"), pattern="^menus\\.txt$", full.names=TRUE)
>>>>> a reasonable replacement for the Sys.glob() construction in Rcmdr? I
>>>>> don't
>>>>> want to suggest to Prof. Fox an amendment which fixes my problem but
>>>>> 'breaks' it for others!
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> Keith Jewell
>>>>>
>>>>> R version 2.13.0 (2011-04-13)
>>>>> Platform: i386-pc-mingw32/i386 (32-bit)
>>>>>
>>>>> locale:
>>>>> [1] LC_COLLATE=English_United Kingdom.1252
>>>>> [2] LC_CTYPE=English_United Kingdom.1252
>>>>> [3] LC_MONETARY=English_United Kingdom.1252
>>>>> [4] LC_NUMERIC=C
>>>>> [5] LC_TIME=English_United Kingdom.1252
>>>>>
>>>>> attached base packages:
>>>>> [1] datasets  grDevices splines   graphics  stats     utils     tcltk
>>>>> [8] tools     methods   base
>>>>>
>>>>>
>>>>>
>>>>
>>>> ______________________________________________
>>>> R-help at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>>> PLEASE do read the posting guide
>>>> http://www.R-project.org/posting-guide.html
>>>> and provide commented, minimal, self-contained, reproducible code.
>>>
>>
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>

More information about the R-help mailing list