Directory not found when using Drat on a network drive

Question

I have developed a package that I want to share with my colleagues at work.

I have a network drive in which I created the local repository structure that looks like this:

MyRepo
\__bin
   \__windows
      \__contrib
\__src
   \__contrib

All folders are empty.

So I built my package with RStudio on Windows using the "Build/More/Build source package" menu, which created a tar.gz file.

Then I tried:

drat::insertPackage("../myPkg_0.0.0.9000.tar.gz",
                    repodir = "file://networkdrive/path/to/MyRepo",
                    action = "prune")

But this gives me an error:

Error: Directory file://networkdrive/path/to/MyRepo not found

Which is strange because file.exists(//networkdrive/path/to/MyRepo) returns true.

OK, then I tried:

drat::insertPackage("../myPkg_0.0.0.9000.tar.gz",
                    repodir = "//networkdrive/path/to/MyRepo",
                    action = "prune")

Without the file: in the repository path and I get another error:

tar (child): "//networkdrive/path/to/MyRepo/src/contrib/myPkg_0.0.0.9000.tar.gz: Cannot open: No such file or directory
tar (child): Error is not recoverable: exiting now
/usr/bin/tar: Child returned status 2
/usr/bin/tar: myPkg/DESCRIPTION: Not found in archive
/usr/bin/tar: Exiting with failure status due to previous errors
reading DESCRIPTION for package ‘myPkg’ failed with message:
  cannot open the connection

But when I go in the "//networkdrive/path/to/MyRepo/src/contrib" folder, I can definitely see the myPkg_0.0.0.9000.tar.gz file that has been copied despite the error message.

Can anyone help?

> sessionInfo()
R version 3.3.3 (2017-03-06)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1

locale:
[1] LC_COLLATE=French_France.1252  LC_CTYPE=French_France.1252    LC_MONETARY=French_France.1252 LC_NUMERIC=C                   LC_TIME=French_France.1252    

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
[1] drat_0.1.2   tools_3.3.3  git2r_0.18.0

Answer 1

Ok, so after some research, here is my conclusions.

• It cannot be done
• It's not Drat's fault

The reason why it does not work is that the tools::write_PACKAGES function does not work on network drives. Period.

I manually copied my package on the network drive, then ran setwd() to its location and executed write_PACKAGES(".", type="source") and I got the same error.

So to make this work, I just left my package.tar.gz file on a local drive, ran the tools::write_PACKAGES command locally and then moved the files to the network drive.

Adding the network drive to my repository list using options(repos = c(MyRepo = "file://networkdrive/path/to/MyRepo/")) works: RStudio and available.packages find my package.

It's not completely satisfactory, but I think it's the only way today.

Answer 2

I was having this problem as well and finally got to the bottom of it today.

For me, the problem was not isolated to just network locations but also occurred on C: drive. The root cause was the version of tar.exe being used to unpack the existing packages in the package directory. Calls to utils::untar are made in the tools::write_PACKAGES function.

The documentation for utils::untar explains that on Windows, external tar.exe is tried first. Sure enough, I had a version installed with Git which when used with default arguments fails when a colon is in the file name. I was able to force utils::untar to use to use the RBuildTools version of tar.exe instead by setting the environment variable TAR to "internal".

drat::insertPackage now works.

Answer 3

I know this is old, but my colleague just came across the same problem and found this post. I believe the issue may be the lack of a trailing slash in your directory name. I have been able to recreate the error with a mapped network drive. I can resolve the issue by using "H:/MyRepo/" instead of "H:/MyRepo".

I haven't tried it with the "file://" format, but I wanted to include my answer in case someone else comes across this question.