[Rd] update.packages fails with directory not found

[peter dalgaard]

On May 11, 2010, at 12:35 PM, Georgi Boshnakov wrote:

> I posted a similar problem to this list but had no response.
> The full email is copied below.

Well, things sometimes just fly by....

> 
> 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?
> 

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

> [...much snippage...]
>  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)
>  ...

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.  

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

-- 
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com