[Rd] update.packages fails with directory not found

Duncan Murdoch murdoch.duncan at gmail.com
Tue May 11 13:47:38 CEST 2010


On 11/05/2010 6:35 AM, Georgi Boshnakov wrote:
> I posted a similar problem to this list but had no response.
> The full email is copied below.
>   

Thanks for reposting this.  I didn't see the original (I was travelling 
at the time).
> In a nutshell, I traced the message to normalizePath,
> which issues it. The directory does not exist because a "move/rename  
> directory" command, issued at the end of the installation, failed. The  
> directory you see would have been renamed to the eventual one otherwise.
>   

I'll change normalizePath to generate a warning rather than an error.  
This may allow processing to continue.
> Since it is the move/rename command which fails on otherwise  
> (seemingly) successful installation, is it possible to try to copy the  
> directory when renaming fails and, if successful, inform the user that  
> a temporary directory has been left behind?
>   

It was just a warning message about not moving the directory.  But the 
warning message itself triggered an error, which stopped the install.  
So maybe things will be okay if we just stop the error.

The big problem with this particular bug is that it is not reproducible 
on demand.  So I can make changes, but I have no idea if they are effective.

Duncan Murdoch
>
> Georgi Boshnakov
> Univeristy of Manchester
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 10 May 2010 00:07:50 -0400
> From: Mike Prager <mike.prager at mhprager.com>
> To: r-devel at stat.math.ethz.ch
> Subject: [Rd] update.packages fails with directory not found
> Message-ID: <t81fu5t8gg8crt5nm3h3d3rg6bcg7lri7k at 4ax.com>
> Content-Type: text/plain; charset=us-ascii
>
> Windows XP.  I have just updated to R 2.11.0 and then run
> update.packages. In the series of updates, a few will succeed, then I
> get a failure like
>
>
> package 'mvtnorm' successfully unpacked and MD5 sums checked
> package 'party' successfully unpacked and MD5 sums checked
> package 'PBSmodelling' successfully unpacked and MD5 sums checked
> Error in normalizePath(path) :
>    path[1]="c:\Program Files\R\Library/PBSmodelling": The system cannot
> find the file specified
>
>
> Indeed, the path is missing, though it was there when I issued the
> update.packages command.
>
> ???
>
> --
> Mike Prager, NC, USA
>
>
>
> ------------------------------
>
>
>
> ----- Forwarded message from georgi.boshnakov at manchester.ac.uk -----
>      Date: Thu, 18 Feb 2010 10:43:11 +0000
>      From: Georgi Boshnakov <georgi.boshnakov at manchester.ac.uk>
>   Subject: install.packages, normalizePath, file permissions
>        To: r-devel at r-project.org
>
> Dear developers,
>
> I have a small but more or less well defined inquiry. Another, more  
> general one for which I was not able to find information is towards  
> the end of this messages. The question seems to be too technical for  
> R-help, that is why I post it here.
>
> When installing packages (Windows XP), occasionally the installation  
> does not complete because, it seems, Windows locks some files. I  
> normally ignore this as a minor annoyance but now I wish to ask  
> students to install a number of often used packages by sourcing an R  
> file and this becomes a problem.
>
> Here is an example:
>
>   
>> install.packages( file.path(fp,"fgui_1.0-0.zip"     ), repos=NULL)
>>     
> Warning in install.packages(file.path(fp, "fgui_1.0-0.zip"), repos = NULL) :
>    argument 'lib' is missing: using 'p:/Rpack'
> package 'fgui' successfully unpacked and MD5 sums checked
> Error in normalizePath(path) :
>    path[1]="p:\Rpack/fgui": The system cannot find the file specified
>
>
> The circumstances are difficult to reproduce. For some reason, the  
> system does not like "fgui" and maybe other packages. The p: drive  
> above is network attached and and I have read/write access. Here is  
> the result of traceback.
>
>   
>> traceback()
>>     
> 7: normalizePath(instPath)
> 6: sprintf(gettext(fmt, domain = domain), ...)
> 5: gettextf("unable to move temporary installation '%s' to '%s'",
>         normalizePath(file.path(tmpDir, curPkg)), normalizePath(instPath))
> 4: warning(gettextf("unable to move temporary installation '%s' to '%s'",
>         normalizePath(file.path(tmpDir, curPkg)), normalizePath(instPath)),
>         domain = NA, call. = FALSE, immediate. = TRUE)
> 3: unpackPkg(pkgs[i], pkgnames[i], lib)
> 2: .install.winbinary(pkgs = pkgs, lib = lib, contriburl = contriburl,
>         method = method, available = available, destdir = destdir,
>         dependencies = dependencies, ...)
> 1: install.packages(file.path(fp, "fgui_1.0-0.zip"), repos = NULL)
>
> The error seems to be thrown by the folloing chunk towards the end of  
> .install.winbinary():
>
>    ret <- file.rename(file.path(tmpDir, curPkg), instPath)
>    if(!ret)
>      warning(gettextf("unable to move temporary installation '%s' to '%s'",
>                       normalizePath(file.path(tmpDir, curPkg)),
>                       normalizePath(instPath)),
>               domain = NA, call. = FALSE, immediate. = TRUE)
>    ...
>
> Apparently, renaming failed and a message is displayed.
> The failure of rename.file may have left the directory specified by  
> 'instPath' non-existent which may cause normalizePath to fail. When  
> this happens
> the message printed is not that of warninig() but the one from  
> normalizePath() which is uninformative for the user. Maybe an  
> additional check here would be appropriate and, given that the  
> installation has been basically successful at this point, even an  
> attempt to copy the directory after the refusal by Windows to rename  
> it? I understand of course that the developers have better things to  
> do than to wrestle with the caprice of Windows.
>
>
> ====
> Here is a more general enquiry.
>
> I am using R in a statistics course (about 100) students in a computer  
> cluster where R is installed on a server, students run WindowsXP and  
> to my understanding the program is run by something called "Zen". It  
> seems that if a number of students try loading packages, things become  
> extremely slow and loading fails for some.
>
> The IT services claim that R is the culprit, I am not sure and  
> certainly part of the problem is related to the slow speed of the  
> network, but a few problems seem to be related to permissions. I tried  
> using options(timeout=N) even trying ridiculous values for N but this  
> did not improve things.
>
> I was not able to trace discussions of such issues and wonder if  
> somebody has encountered similar problems.
>
> I am about to try ask the students to install some packages in their  
> area (called p: drive at this Uni) which prompted the first question  
> above.
>
> Thank you for any suggestions,
> Georgi
>
>
>



More information about the R-devel mailing list