Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

install_github fails with unzip error #1464

Closed
plantarum opened this issue Feb 23, 2017 · 24 comments
Closed

install_github fails with unzip error #1464

plantarum opened this issue Feb 23, 2017 · 24 comments
Labels
bug an unexpected problem or unintended behavior install

Comments

@plantarum
Copy link
Contributor

I'm trying to install my own package from github: plantarum/flowPloidy, onto a Windows computer. Starting from a fresh session, installing devtools from Cran, I try:

install_github("plantarum/flowPloidy", dependencies = TRUE)

This fails with:

Error in utils::unzip(src, exdir = target) : 
  cannot open file 'C:/Users/jamest/AppData/Local/Temp/RtmpKWeuxp/devtools1fc45f5c7551/plantarum-flowPloidy-88ad2c0/R/FlowHist.R': No such file or directory

I looked into those directories, and the toplevel directory 'C:/Users/jamest/AppData/Local/Temp/RtmpKWeuxp/devtools1fc45f5c7551/plantarum-flowPloidy-88ad2c0/ is there, and in the downloaded zip file the R folder exists and contains all the code files as you expect.

I tried debugging my way through the code, and got as far as the function get0 before I gave up trying to figure out the ultimate source of the error.

install_github works no problem for this package under Linux.

Thanks for any help or suggestions,

Tyler

R version 3.3.2 (2016-10-31) -- "Sincere Pumpkin Patch"

@plantarum
Copy link
Contributor Author

I just tried installing the zip file directly and got the same problem, so the problem is probably not with devtools itself?

install.packages("C:/Users/jamest/Downloads/flowPloidy-master.zip", repos = NULL, type = "win.binary")
Error in install.packages : cannot open file 'C:/Users/jamest/Documents/R-3.3.2/library/file4e4c8cc0b/flowPloidy-master/R/FlowHist.R': No such file or directory

@jianlingfan
Copy link

I have the same problem for several weeks too, still looking for a solution.

@alex23lemm
Copy link

alex23lemm commented Apr 4, 2017

Today, I ran into the problem by letting several people install the tutor package using devtools. All Mac and Linux users had no issues and also the installation for the majority of the Windows users went well.

However, some of the Windows users ran into the problem described above which looked as follows in our case:

> devtools::install_github("rstudio/tutor")
Downloading GitHub repo rstudio/tutor@master
from URL https://api.github.com/repos/rstudio/tutor/zipball/master
Error in utils::unzip(src, exdir = target) : 
 cannot open file 'C:/Users/mshumper/AppData/Local/Temp/RtmpeE4D2Q/devtools23e061002ad9/rstudio-tutor-1476bf6/R/ace.R': No such file or directory

All users installed the current R version 3.3.3 and the current RStudio version 1.0.136 today prior to trying to install tutor via devtools.

Even though I am on Windows as well I was not able to reproduce the bug on my machine.

@dfifield
Copy link

This sounds very similar to the problem described in Issue #1433. The work-around was to get rid of .Rbuildignore.

@hadley hadley added bug an unexpected problem or unintended behavior install labels Aug 1, 2017
@hadley
Copy link
Member

hadley commented Aug 1, 2017

@gaborcsardi @jimhester have you seen this before?

@gaborcsardi
Copy link
Member

Haven't. Can't reproduce. Maybe a "wrong" unzip program again? Although I am not sure how removing .Rbuildignore would fix that....

@imanuelcostigan
Copy link
Contributor

This looks like the same bug that has been bedevilling my team for years (!). We all have Windows 7 x64 PC, each with the same corporate "build" and have same admin privileges. Yet install_github() works on my PC, but not on any other person's PC. Everyone else has this same issue. See this SO thread: https://stackoverflow.com/questions/41293748/unzip-fails-using-install-github/41293968

In particular, note this behaviour:

when they download the zip directly from Github's website and try to extract into their user folder, they get the same behaviour from Winzip, but 7-zip can successfully unpack the file.

I've spent quite a bit of time debugging this all to no avail. Squashing this bug would be massive for us.

@gaborcsardi
Copy link
Member

@imanuelcostigan Can you pls share a zip file that is problematic, and also the winzip version your colleagues have?

@hadley
Copy link
Member

hadley commented Aug 2, 2017

@imanuelcostigan you might also try comparing getOption("unzip") on your computer vs. your colleagues

@hadley
Copy link
Member

hadley commented Aug 2, 2017

It's possible that this may also be related to the path length.

@gaborcsardi
Copy link
Member

@hadley In the original error, the path is only about 90 characters long, that should be ok.

@hadley
Copy link
Member

hadley commented Aug 2, 2017

@gaborcsardi good point. I'll keep the other issue open

@imanuelcostigan
Copy link
Contributor

@hadley getOption("unzip") yields "internal" for me.

@pgwatson @jonathanrandall can you please add what you get from the same command to this thread?

Thanks

@jonathanrandall
Copy link

"internal"

@pgwatson
Copy link

pgwatson commented Aug 3, 2017 via email

@pgwatson
Copy link

pgwatson commented Aug 3, 2017 via email

@hadley
Copy link
Member

hadley commented Aug 7, 2017

I'm going to reopen this so we can include some basic fix for devtools (to at least help diagnose the problem)

@hadley hadley reopened this Aug 7, 2017
@imanuelcostigan
Copy link
Contributor

@hadley let me know if my team or I can help provide you any more info.

@jimhester
Copy link
Member

I am pretty sure this issue is only tangentially related to devtools code, the error is coming from the internal unzip code.

https://github.com/wch/r-source/blob/780021752eb83a71e2198019acf069ba8741103b/src/main/dounzip.c#L177

Possible causes could be

  • lack of write permissions in tempdir() or one of the children for the user R is running under
  • tempdir() or one of the child directories being removed. This could be done automatically by certain windows options.

@hadley
Copy link
Member

hadley commented Aug 16, 2017

And devtools does respect the unzip option, so you might able to set the option to overcome your problems (but you might want to check that different versions of zip consistently fail or not in case the problem has a stochastic component).

@hadley
Copy link
Member

hadley commented Aug 16, 2017

I think we'll close this issue since it doesn't seem like devtools' problem - but feel free to continue to contribute insights here (so people find them when googling), and we are likely to explore alternatives to the internal zip utility in remotes.

@hadley hadley closed this as completed Aug 16, 2017
@imanuelcostigan
Copy link
Contributor

@jimhester I'm pretty sure that the issue isn't caused by either of those. We continued to see the same error when setting a different temp directory that users definitely had read/write access to and the directory was not being removed as we were able to see the directory after the process failed. In fact, unzipping the package failed using WinZip with the same sort of error in a user directory.

In summary, what we have found was the unzipping the package:

  • worked for everyone using 7-zip
  • worked for everyone using Github compiled unzip (but per comment above, GH's unzip is compiled differently to the one bundled by R, even though they are the same version)
  • worked for me using WinZip but no one else
  • worked for me using R bundled unzip code, but not for anyone else in my team

@imanuelcostigan
Copy link
Contributor

imanuelcostigan commented Aug 26, 2017

install_github() has now stopped working for me on my new machine. Following @pgwatson suggestion above, here's a work around:

  • Download and install Git.
  • Set the unzip option to version of unzip.exe supplied by Git e.g. options(unzip = "c:/Program Files/Git/usr/bin/unzip.exe"). You can obviously set this option at startup by adding this the .First() function definition in your .Rprofile.

Everything now works.

@lock
Copy link

lock bot commented Sep 17, 2018

This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/

@lock lock bot locked and limited conversation to collaborators Sep 17, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug an unexpected problem or unintended behavior install
Projects
None yet
Development

No branches or pull requests

10 participants