[Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony

[Kevin Coombes]

That's a reasonable theory.  Unfortunately, it is wrong.  The attached
image shows that I was running the Windows command prompt as an
administrator when I got the error message from R CMD check.

I will also point out that on my two desktops and my old laptop, I was able
to run R CMD check or INSTALL with R 2.15 and never had to explicitly
invoke the command prompt in administrator mode; it was enough that I was
an administrator on the machine.  However, it is still possible that this
is a Windows issue rather than an R 3.0 issue; that's obviously the
difficulty when changing both the machine and the R version at once. It
makes debugging painful.

PS: Apologies to Duncan for sending this to him twice;  I accidentally hit
"reply" instead of "reply all" the first time. I hate working on new
machines when I don't yet have all of my tools installed and have to use
ones that I'm less familiar with....


On Fri, Apr 19, 2013 at 7:47 PM, Duncan Murdoch <murdoch.duncan at gmail.com>wrote:

> On 13-04-19 5:37 PM, Kevin Coombes wrote:
>
>> Having finally found some free time, I was going to use it to update a
>> bunch of R packages from 2.15 to 3.0.
>>
>> I am running Windows 7, 64-bit professional.  This is on a brand-new
>> laptop using vanilla settings when installing the operating system.
>>
>> Problem 1: I installed R3.0 to the default location (C:\Program
>> FIles\R\R-3.0.0).  The first thing I tried to do was install
>> BioConductor.  This failed (permission denied). Thinking that this might
>> be a BioConductor problem, I then tried to install a (semirandom)
>> package from CRAN.  This also failed.
>>
>> In both cases, when using the GUI, the error message is almost
>> incomprehensible.  You get a pop-up window that *only* says "Do you want
>> to use a private library instead?"  Since this wasn't what I wanted to
>> do I said "no".  Only after the pop-up closes does the command window
>> print the error message telling me that permission was denied for R to
>> write to its own library location.
>>
>
> This is a standard Windows problem, to stop viruses from modifying
> installed programs.  The standard Windows solution to it is to run the
> installer as an administrator, taking personal responsibility for
> installing the package/virus.
>
> Since this is a laptop, you could probably do this, but it's possible that
> you are not the administrator on your system.  If that's the case, you
> should ask your administrator to do the install.
>
>
>
>> Dumb Fix to Problem 1: So, I uninstalled R and then reinstalled to a
>> nonstandard location (C:\R\R-3.0.0).  Now I can successfully install
>> packages from CRAN and BioConductor (hooray!). But I run directly into:
>>
>
> That's another solution, and a third solution is to accept the offer R
> made, to install your packages somewhere where you as a user have write
> permission.
>
>
>
>> Problem 2: Emacs Speaks Statistics (ESS) can no longer find the R
>> binary. When R was installed in the default location, ESS worked. When R
>> 2.15 (or earlier) was installed in the same nonstandard location, I
>> could get ESS to find the R binaries by including (setq
>> ess-directory-containing-r "C:") in my .emacs file, but that no longer
>> works.
>>
>> Dumb Fix to Problem 2:  Hack into ess-site.el and put the complete,
>> explicit path to the correct binary into
>> (setq-default inferior-R-program-name 'FULLPATHHERE")
>> which will break as soon as I upgrade R (assuming I am foolish enough to
>> ever do that again).
>>
>
> I can't help you with ESS.
>
>
>>
>> Now I am ready to rebuild my R packages.  I have this nice perl script
>> that goes through the following procedure:
>>
>> 1. Set the path to include the correct Rtools directory.  (For reasons
>> that Gabor Grothendieck has pointed out previously, this is not a
>> permanent part of the path since doing so would override some built-in
>> Windows commands.)
>>
>
> Just curious:  how often do you use the Windows find command?  We have put
> instructions in place for people to run the install process with a renamed
> Rtools find command (which I think is the only conflict). The issue is that
> more users who want to use the command line commands are familiar with the
> Unix variant (which came first, by the way) than the Windows one, so
> renaming the Rtools one would cause trouble for more people.
>
>
>  2. Build a source tarball via
>>       R CMD build $package
>> 3. Build a Windows binary version (as a zip file) via
>>       R CMD INSTALL --build $tarball
>> 4. Check the package via
>>       R CMD check --as-cran $tarball
>> 5. Install the package via
>>       R CMD INSTALL $tarball
>>
>> Problem 3: Step 3 fails, withe the error message "Running 'zip' failed".
>>
>> Dumb Fix to Problem 3: Install the GnbuWin32 version of zip, and make
>> sure that its location is earlier in ter path than the version that
>> comes with Rtools.
>>
>
> I have no idea about this one.
>
>
>
>> Problem 4: Step 4 fails when running the test scripts that accompany the
>> package.  The error message is the semicryptic
>>       "cannot open file 'c:\Users\krc\AppData\Local\**Temp\Rtmp....'
>> Permission denied"
>>
>
> That's Windows permissions biting you again.  Run as administrator.
>
> Duncan Murdoch
>
>  Dumb Fix to Problem 4: Write this email message and hope someone with
>> even more patience than I have has already found a better way to get all
>> this stuff to work.
>>
>> Tired of spinning my wheels,
>>       Kevin
>>
>> ______________________________**________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/**listinfo/r-devel<https://stat.ethz.ch/mailman/listinfo/r-devel>
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: admin-command.png
Type: image/png
Size: 42228 bytes
Desc: not available
URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20130419/61fdea84/attachment.png>