install.packages() - old version deleted, new version did not install

On 20/12/2010 9:03 AM, Jon Olav Skoien wrote:

On 12/20/2010 1:43 PM, Duncan Murdoch wrote:

Jon Olav Skoien wrote:

On 12/17/2010 6:22 PM, Duncan Murdoch wrote:

On 17/12/2010 11:13 AM, Jon Olav Skoien wrote:

Dear list,

(R 2.12.0, Windows 7, 64bit)

I recently tried to install a new package ("spacetime"), that
depends on
"sp" among others. I already had the last one installed, but

there was

probably a newer version on CRAN, so the command

install.packages("spacetime")

also gave me:
also installing the dependencies ?sp?, ?zoo?, ?xts?

sp was already loaded in this session, so installation failed:
package 'sp' successfully unpacked and MD5 sums checked
Warning: cannot remove prior installation of package 'sp'

Unfortunately, the warning should rather say:
"cannot completely remove prior installation of package 'sp'"
R managed to remove most of the prior installation of sp, except
for the
.dll. I could go on using sp in the existing sessions, but not load
the
package in a new session or open the help pages. This has happened
to me
several times, and the only solution I have found to this is to

close

all R-sessions and install the package again. This is normally

ok, but

this time I had some long-time computations running in another
R-session
that I did not want to interrupt. For the next time, is there a

way to

reinstall a package without interrupting running R-sessions?

For me it seems like the cause of the problem could have been
solved by
checking if the .dll can be removed before removing the rest of the
package, by adding something like the following in
utils:::unpackPkgZip?
if (unlink(paste(instPath,"/libs/x64/sp.dll", sep = "")) != 0)
warning("cannot remove...")
before
ret<- unlink(instPath, recursive = TRUE) (line 95)
x64 in the path would have to be changed to something architecture
dependent...

Could you try out the new 2.12.1 release? I recall hearing that
something like this had changed, but I can't spot the NEWS item
right now.

Duncan Murdoch

It seems it didnt change yet...
I installed 2.12.1 (on a different computer, still Windows, but Vista
and 32 bit), and after installing and loading sp in one session, I
opened a new session and got:

R version 2.12.1 (2010-12-16)
Copyright (C) 2010 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
Platform: i386-pc-mingw32/i386 (32-bit)
............................

install.packages("sp")

Installing package(s) into ?C:\Users\Jon\Documents/R/win-library/2.12?
(as ?lib? is unspecified)
--- Please select a CRAN mirror for use in this session ---
provo con l'URL
'http://cran.at.r-project.org/bin/windows/contrib/2.12/sp_0.9-76.zip'
Content type 'application/zip' length 997444 bytes (974 Kb)
URL aperto
downloaded 974 Kb

package 'sp' successfully unpacked and MD5 sums checked
Warning: cannot remove prior installation of package 'sp'

The downloaded packages are in
C:\Users\Jon\AppData\Local\Temp\RtmpCTJeBk\downloaded_packages

library(sp)

Errore in library(sp) : non c'? alcun pacchetto chiamato 'sp'

The error message is the same as earlier, there is no package called
"sp", the attempt to install it again removed the old version except
for the .dll.

Jon

Did you have it open at the time? Windows won't let open files be
removed, so that could have caused the problem. If it's not that, it
could be a permissions problem. Have you tried running R as
administrator for the install?

Yes, I had it open. In this case it was intentional to give a
reproducible example in case something had changed in the new version,
in other cases I have had to wait for 2 days before I could reinstall a
package. It seems the .dll is the one causing the problem, so wouldnt it
be possible to test if this file can be unlinked before trying to unlink
the complete directory in utils:::unpackPkgZip? Then the package should
be left untouched if it is in use, and not partly deleted as today.

I don't know. Perhaps we could try to rename the folder; if that fails,
abort the whole thing. If that succeeds but something later fails, then
remove all the new stuff and restore the old folder. Do you know of a
better test?

Duncan Murdoch

I know that it is possible to avoid this problem by not installing a
package in use, but
1) it seems only to affect packages with .dll's, so some packages can be
reinstalled while in use
2) you dont always know if a dependent package will download a new
version of an installed package

Best wishes,
Jon