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

[Duncan Murdoch]

On 20/12/2010 9:29 AM, Duncan Murdoch wrote:
> On 20/12/2010 9:26 AM, Uwe Ligges wrote:
> >
> >  On 20.12.2010 15:19, Duncan Murdoch wrote:
> >  >   On 20/12/2010 9:03 AM, Jon Olav Skoien wrote:

[ lots deleted ]

> >  >>   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?
> >
> >  I think we had something like that in the past which did not work
> >  properly on network shares and we had to change the way it works for
> >  that reason.
>
> I just took a look at the code, and I see that something like that is
> still there.  I haven't tried it yet, so I don't know if it is in use.

After a closer look I see that the code is there for source installs, 
but not binary installs.  For binary installs the procedure is:

  unzip the package to a temporary directory
  look at the DESCRIPTION to find the package name (since you can't 
trust the .zip name)
  abort if the package is in the search list.  (This is the test that 
could be stronger, because it doesn't detect a package in use in another 
instance of R.)
  remove the old package if it is there.  (This is the step that removes 
everything but the old DLL when the DLL is in use.)
  copy the new package into place. (This fails because of the collision 
with the old DLL.)

I'll look into strengthening the test at the 3rd step with something 
along the lines described above.  From Uwe's description, this might 
still not
be perfect, but it should help with local installs.

Duncan Murdoch