Re: [Rd] unpackPkgZip: "unable to move temporary installation" due to antivirus
This windows/anti-virus problem has been worked around in R-devel 73329.
Thanks to Mike for reporting this and testing the changes.
Best
Tomas
On 09/13/2017 01:40 AM, Mike Toews wrote:
Hi,
Me and an office colleague on Microsoft Windows 10 PCs are having
difficulty installing any package. This is a recent issue for us, and
we suspect our McAfee antivirus has modified by our IT department.
Let's take, for example, install.packages("mypackage"), here is the
output:
package ‘mypackage’ successfully unpacked and MD5 sums checked
Warning in install.packages :
unable to move temporary installation
‘C:\Users\mtoews\Documents\R\win-library\3.3\file382064842da2\mypackage’
to ‘C:\Users\mtoews\Documents\R\win-library\3.3\mypackage’
Debugging, I found the issue around here:
https://github.com/wch/r-source/blob/980c15af89d99c04e09a40708512a57c49d1c6ee/src/library/utils/R/windows/install.packages.R#L173-L174
## To avoid anti-virus interference, wait a little
Sys.sleep(0.5)
As indicated by an answer
(https://stackoverflow.com/a/44256437/327026), debugging slows down
the function to allow the package to be installed. A simple fix is to
increase the sleep time to a time that is longer than 0.5 seconds.
(I've tried testing new times, but I can't seem to overload this
function). Or use a different strategy, such as using a few attempts
with increasing wait times, or using a custom unlink function.
Happy to help out or test more on this issue. Also, if any R Core
member could add me to R's Bugzilla members, that would be convenient
for me.
Cheers,
Mike
R version 3.3.3 (2017-03-06) -- "Another Canoe"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] calling R API functions after engine shutdown
Hi!
We’ve recently come across an example where a package (minqa) creates an Rcpp
Function object in a static variable.
This causes R_ReleaseObject to be called by the destructor at a very late point
in time - as part of the system exit function:
static Function cf("c");
I’m wondering if that is considered to be “safe”?
Is the R engine supposed to stay in a state where calls to API functions are
valid, even after it has shut down?
It probably only ever happens with the ReleaseObject function, but even that
could cause problems, e.g., with more elaborate refcounting schemes.
- Lukas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] calling R API functions after engine shutdown
Calling R_ReleaseObject in a C++ destructor is not reliable - it can be
bypassed by a non-local return, such as an error. Generally in R one
cannot use C++ destructors reliably for anything that the R runtime
wouldn't do on its own in case of a non-local return.
A destructor that calls just UNPROTECT, in a way that balances out the
protection stack (e.g. Rcpp Shield), is safe because R runtime balances
the protection stack on non-local return. Destructors used in code that
will never call into any R API (such as in a third party library) are
safe, because the R runtime could not do non-local return. All other
destructors are a problem.
UNPROTECT will work even during R shutdown.
In some cases cleanup code that would be put in C++ destructors, if they
were safe with R, can instead be put into R finalizers.
Tomas
On 09/21/2017 04:41 PM, Lukas Stadler wrote:
Hi!
We’ve recently come across an example where a package (minqa) creates an Rcpp
Function object in a static variable.
This causes R_ReleaseObject to be called by the destructor at a very late point
in time - as part of the system exit function:
static Function cf("c");
I’m wondering if that is considered to be “safe”?
Is the R engine supposed to stay in a state where calls to API functions are
valid, even after it has shut down?
It probably only ever happens with the ReleaseObject function, but even that
could cause problems, e.g., with more elaborate refcounting schemes.
- Lukas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build errors if files cannot be moved, even if they are in Rbuildignore
When a package is built it is first moved to a temporary directory (lines
962-980 in build.R). However, this moves *all* files to the temporary
directory, even those in Rbuildignore; only later (lines 997-1024) are
Rbuildignore files excluded.
The problem with this approach is that some files in the package directory
may not be movable. On Windows at least, the full path name to a file must
not be overly long (around 250 chars). Attempting to copy such files using
`file.copy` is a warning, and ultimately fails. In particular, if a package
uses a `data-raw` folder to prepare data, and data-raw/ contains such long
files, R CMD build will not work, meaning that the data-raw folder has to
be manually stashed before building.
I propose that the following line
if (!file.copy(pkgname, Tdir, recursive = TRUE, copy.date = TRUE))
should be replaced by something like the following
include <- allfiles[!inRbuildignore(allfiles, pkgdir)] # possibly the rest
of the exclude conds too
mov2Tdir <- function(x) {
file.copy(x, file.path(Tdir, x), copy.date = TRUE)
}
if (any(!vapply(include, mov2Tdir, FUN.VALUE = logical(1
This change would preserve the error condition, but not erroneously when
failing to copy files which will never be built.
This may or may not make the unlink(allfiles[exclude], recursive = TRUE,
force = TRUE) line redundant; I'm not sure.
Hugh Parsonage
Grattan Institute.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
