Hi,
Already reported here:
https://stat.ethz.ch/pipermail/r-devel/2010-September/058636.html
but it doesn't seem to be related (at least not in an obvious way) to
the problems described in that previous thread.
So the problem is that, with recent versions of R 2.12 (i.e.
current R-alpha but I've observed this with R-devel for at
least 2-3 months now), 'R CMD build <somepkg>' on Windows will
fail on a random set of Bioconductor packages because of a tar
problem. For example:
R/bin/R.exe CMD build OLIN
* checking for file 'OLIN/DESCRIPTION' ... OK
* preparing 'OLIN':
* checking DESCRIPTION meta-information ... OK
/cygdrive/c/RTOOLS?1/bin/tar: OLIN/data/sw.olin.RData: Cannot change
ownership to uid 0, gid 401: Invalid argument
/cygdrive/c/RTOOLS?1/bin/tar: OLIN/data/sw.RData: Cannot change
ownership to uid 0, gid 401: Invalid argument
/cygdrive/c/RTOOLS?1/bin/tar: OLIN/data/sw.xy.RData: Cannot change
ownership to uid 0, gid 401: Invalid argument
/cygdrive/c/RTOOLS?1/bin/tar: OLIN/data: Cannot change ownership to
uid 0, gid 401: Invalid argument
...
[many lines like this]
...
/cygdrive/c/RTOOLS?1/bin/tar: OLIN: Cannot change ownership to uid 0,
gid 401: Invalid argument
/cygdrive/c/RTOOLS?1/bin/tar: Exiting with failure status due to
previous errors
ERROR
copying to build directory failed
19 Bioconductor packages were victim of that bug during yesterday's
builds, 22 the day before, etc... this looks completely random and
therefore is hard to reproduce.
The following patch:
Index: src/library/tools/R/build.R
==================================================================---
src/library/tools/R/build.R (revision 53069)
+++ src/library/tools/R/build.R (working copy)
@@ -515,7 +515,7 @@
## The tar.exe in Rtools has --force-local by default, but this
## enables people to use Cygwin or MSYS tar.
TAR <- Sys.getenv("TAR", NA)
- TAR <- if (is.na(TAR)) {if (WINDOWS) "tar --force-local" else
"tar"}
+ TAR <- if (is.na(TAR)) {if (WINDOWS) "tar --force-local
--no-same-owner" else "tar"}
else shQuote(TAR)
GZIP <- Sys.getenv("R_GZIPCMD")
if (!nzchar(GZIP)) GZIP <- "gzip"
seems to address the problem even though I admit it doesn't provide
a lot of insight about what's really going on. But it seems safe.
Could it be applied as a workaround?
If that is not desirable, could the tools:::.build_packages() function
not put quotes around the value of the TAR environment variable (the
code does shQuote(TAR)), at least on Windows, so I can set this
variable to
tar --no-same-owner
Note that the use of quotes around TAR is inconsistent across
utils::untar(), utils::tar() and tools:::.build_packages() (only
the first doesn't put them) but that's another story.
Thanks!
H.
--
Herv? Pag?s
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpages at fhcrc.org
Phone: (206) 667-5791
Fax: (206) 667-1319