Skip to content

update.packages fails with directory not found

8 messages · Georgi Boshnakov, Peter Dalgaard, Mike Prager +1 more

Original
Georgi Boshnakov
# 
I posted a similar problem to this list but had no response.
The full email is copied below.

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.

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?


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:
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.
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


-- 
Dr Georgi Boshnakov               tel: (+44) (0)161 306 3684
School of Mathematics             fax: (+44) (0)161 306 3669
Alan Turing Building 1.125
The University of Manchester      email: Georgi.Boshnakov at manchester.ac.uk
Oxford Road
Manchester M13 9PL
UK




----- End forwarded message -----
Duncan Murdoch
#
On 11/05/2010 6:35 AM, Georgi Boshnakov wrote:
Thanks for reposting this.  I didn't see the original (I was travelling 
at the time).
I'll change normalizePath to generate a warning rather than an error.  
This may allow processing to continue.
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
Peter Dalgaard
#
On May 11, 2010, at 12:35 PM, Georgi Boshnakov wrote:

            

      
      
      
    

        
Well, things sometimes just fly by....

            

      
      
      
    

        
Looks like there is a fundamental issue to solve first, anyway:

            

      
      
      
    

        
Yes, as your analysis below more or less indicates: There is a logical problem here! If we can only normalize paths to existing files, then we can not use normalizePath in warning messages saying that we couldn't create them.

The internal issue would seem to be that do_normalizepath internally calls and checks for success of GetLongPathName or its -W version, and I expect that cannot work on paths that don't exist.

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
I've now also committed a change to the file.rename code (on Windows) so 
that it waits for the file copy to complete before returning.  It seems 
possible that it was returning too early, so the next step of the 
install failed.

I'd appreciate it if you could check whether the problems remain in 
R-devel, revision 51980 or later.  (A build of this revision should be 
on CRAN by tomorrow, at 
http://cran.r-project.org/bin/windows/base/rdevel.html .)

Duncan Murdoch

        
On 11/05/2010 7:47 AM, Duncan Murdoch wrote:

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Mike Prager
    

    

      
      #
    

  


  

      
On Tue, 11 May 2010 11:05:45 -0400, Duncan Murdoch

        
<murdoch.duncan at gmail.com> wrote:

        

            

      
      
      
    

        
Thanks for trying to fix this. Here is a cut-and-paste [...edited]
from Rgui.exe.  Hope it helps.  MHP


R version 2.12.0 Under development (unstable) (2010-05-11 r51980)
Copyright (C) 2010 The R Foundation for Statistical Computing
ISBN 3-900051-07-0  [...]

  Natural language support but running in an English locale

[...]
Loading required package: survival
Loading required package: stats
Loading required package: utils
Loading required package: graphics
Loading required package: splines

Attaching package: 'Hmisc'
[...]

            

      
      
      
    

        
trying URL [...]
downloaded 1.0 Mb

package 'maps' successfully unpacked and MD5 sums checked
package 'rgl' successfully unpacked and MD5 sums checked
package 'rJava' successfully unpacked and MD5 sums checked
Warning: unable to move temporary installation 'c:\Program
Files\R\Library\file390c7e87\rJava' to 'c:\Program
Files\R\Library\rJava'
package 'strucchange' successfully unpacked and MD5 sums checked
package 'svMisc' successfully unpacked and MD5 sums checked
package 'tkrplot' successfully unpacked and MD5 sums checked
package 'vcd' successfully unpacked and MD5 sums checked
package 'XML' successfully unpacked and MD5 sums checked
package 'zoo' successfully unpacked and MD5 sums checked

The downloaded packages are in
        C:\Documents and Settings\mike.prager\Local
Settings\Temp\RtmpyrBgXD\downloaded_packages
Warning message:
In normalizePath(path) :
  path[1]="c:\Program Files\R\Library/rJava": The system cannot find
the file specified

            

      
      
      
    

        
No traceback available

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 11/05/2010 6:21 PM, Mike Prager wrote:

            

      
      
      
    

        
Was rJava among the packages loaded at the time you tried this?

            

      
      
      
    

        
After the install was complete, was rJava present in Library?  Was it 
updated?  Was the temporary directory file390c7e87 still present?

Duncan Murdoch

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Mike Prager
    

    

      
      #
    

  


  

      
Shortened a bit further. Answers to queries are at the end.  MHP

Duncan Murdoch wrote on 5/11/2010 7:03 PM:

            

      
      
      
    

        
[...]

            

      
      
      
    

        
Answers:

rJava was not loaded when the update started.
After the install, rJava was no longer present in the library.
The temporary directory file390c7e87 was not present.  Checking my 
undelete program, the temp directory had existed and had contained the 
rJava package but was (and is) deleted.

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 12/05/2010 12:42 PM, Mike Prager wrote:

            

      
      
      
    

        
I don't know what the problem is.  My current guesses:

  - Antivirus bugs.  Are you running some AV program?  Sometimes they 
interfere with other programs.
  - Permissions problems.  I don't know why rJava would have had 
different permissions than the other packages you successfully updated, 
but if it did, that could be a cause.
  - Windows bug.  R uses Windows services to move the temporary 
directory into place, and that's failing for no apparent reason. 

If you can follow Bill Dunlap's advice and monitor the process as it's 
taking place, you might be able to diagnose this, but I don't see a way 
to make any progress otherwise.

Duncan Murdoch