Windows: trouble finding tar/rtools

[jeroen]

Where does it come up with /Rtools/bin?

[cderv]

I think it is from here https://github.com/r-lib/remotes/blob/2dd6a5d9713961e6cbc2a8818f3369103d6e705b/R/utils.R#L163-L181

If available atar found in PATH seems to be used with system2 to check if it can be used with --force-local. If so utils::untar is used with this option, but utils::untar uses internal method or the binary provided if Sys.getenv("TAR"). This could be different from the one in PATH called by system2 🤔

It seems in you case, tar binary called is the one in Rtools/bin/. Do you have one of the environment variable PATH or TAR that could lead to that ? For me Sys.which("tar") is not the one in Rtools/bin so I have the same message but not beginning by /Rtools/bin/tar like you. And Sys.getenv("TAR") is empty.

[gaborcsardi]

@cderv seems like a bug, will fix asap.

[jeroen]

Somebody else on Linux emailed me this:

> remotes::install_github("ropensci/magick")

Downloading GitHub repo ropensci/magick@master
sh: /bin/gtar: No such file or directory
sh: /bin/gtar: No such file or directory
Error in system(cmd, intern = TRUE) : error in running command
In addition: Warning message:
In utils::untar(tarfile, ...) :
  ‘/usr/bin/gzip -dc '/tmp/RtmpaHbZBq/file22d9773efe613.tar.gz' | /bin/gtar -xf '-' -C '/tmp/RtmpaHbZBq/remotes22d977f16b16d'’ returned error code 127

[jimhester]

These are really bugs in utils::untar() / the R configuration, not really in remotes, but probably many people don't run into them because they never try to untar anything with R.

[jeroen]

Doesn't install.packages need untar() to extract the source package?

[jimhester]

install.packages() / R CMD INSTALL seem to essentially force the use of internal untar, maybe we should do the same...

            if (utils::untar(pkg, exdir = tmpdir,
                             tar =  Sys.getenv("R_INSTALL_TAR", "internal")))

https://github.com/wch/r-source/blob/828a04f9c428403e476620b1905a1d8ca41d0bcd/src/library/tools/R/install.R#L1565-L1566

[jeroen]

I think that would make sense. This config is most likely to work.

[cderv]

So basically, the current behavior comes from a non empty Sys.getenv("TAR") that gets picked up ? Because utils::untar already defaults to internal if no env TAR is found.

[gaborcsardi]

Well, the current behavior is buggy, first of all, for the reason you said above. Second, yeah, it is safer to use internal tar, but it is so slooooow, and it does choke on symlinks afair.

[gaborcsardi]

Honestly, the easiest would be to bundle a static tar binary.

[jimhester]

in the linux case yes likely TAR is set to /bin/gtar on that system for some reason. On windows if TAR is unset it uses Sys.which("tar.exe")

[cderv]

On windows if TAR is unset it uses Sys.which("tar.exe")

this is what I missed in untar source definition. Thanks. I had one part of the issue. Got it all now.

[jeroen]

Turns out this person was using the anaconda version of R which is probably the reason it is improperly configured (i.e. TAR="gtar" without formally depending on gtar). So we can probably ignore this case.

[jimhester]

We have seen this gtar issue with anaconda a couple other times, it seems quite long standing (and clearly others are running into this as well based on the upvotes) https://github.com/r-lib/devtools/issues/379#issuecomment-242127532, https://github.com/r-lib/devtools/issues/1722#issuecomment-370019534, I don't really understand why they are setting TAR to a location that doesn't exist...

[jeroen]

@mingwandroid would it be possible to fix this in the conda R build? Either unset the $TAR variable or ensure R depends on gtar.

[mingwandroid]

Will investigate. Thanks!

[fairliereese]

Are there any workarounds for this? I'm encountering this issue still when using a conda R installation.

[gaborcsardi]

@fairliereese have you tried the workarounds mentioned above?

[fairliereese]

I didn't realize that solutions were listed in the linked thread. The export TAR=/bin/tar worked for me. Thanks.