On Windows, dir.create() with recursive=TRUE attempts to create each directory in the path, even if it already exists. This is problematic when the user has restricted write access, for instance, on a network share. For example:
> dir.create('\\\\sharename\\Empl\\Home1\\active\\e\\ecortens\\thisisatest', recursive = TRUE)
In dir.create("\\\\sharename\\Empl\\Home1\\active\\e\\ecortens\\thisisatest", :
cannot create dir '\\ad.mtroyal.ca\Empl', reason 'Permission denied'
I have write access within "ecortens", but, naturally, not within the root of the network share, so it's erroring because it's trying to create "Empl" in a directory that I can't write to.
This is problematic, for instance, in the creation of the 00LOCK directory in install.packages(), which is a call to dir.create() with recursive=TRUE.
I'm not comfortable enough with my C abilities to submit a patch, but the fix, I think, is around line 2170 of src/main.c (in the latest R-devel, checked out from subversion). I know that errno of EEXIST isn't supposed to trigger an exit, but for whatever reason, the Windows API is not setting errno to EEXIST, even though the directory does exist.
The solution, I think, would be to call _wstat() and check that the directory exists, and is a directory, and if so, move to the next chunk of the path, rather than trying to _wmkdir().
R version 3.3.1 (2016-06-21)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
 LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 LC_MONETARY=English_United States.1252 LC_NUMERIC=C
 LC_TIME=English_United States.1252
attached base packages:
 stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
 tools_3.3.1 withr_1.0.2 memoise_1.0.0 digest_0.6.10 devtools_1.12.0
Created attachment 2167 [details]
A patch that will skip both the server and the share
I'm not sure if this is the correct behaviour for all versions of windows. It solves the problem for me, however.
I see that the status of this bug is still UNCONFIRMED, but I can confirm that we have been bit by the same issue while upgrading from R3.2.1 -> R3.4.0
Sorry for the spam.
It does appear to be an issue caused by some change in Windows. I've tested it on several R versions now and all of them (2.15.2, 3.1.1, 3.2.3, 3.4.0) show the same problem. It popped up during upgrade since new directories need to be created when users install packages for the first time from our internal CRAN copy.
I now know this is not an R issue but such failures do affect R's reputation since that is where users run into this problem. So if something can be done to fix it on the R side, e.g. by using Evan's patch that would be great.