It seems it is creating a problem with devtools::check() on R 4.2.0 (but not on 4.1.2). The rstudio.lock file only appears in the Windows Temp folder when opening RStudio with my primary package, not on other packages.
devtools::check()
Warning in file.copy(pkgname, Tdir, recursive = TRUE, copy.date = TRUE) :
problem copying .\rempsyc\.Rproj.user\418BC976\viewer_history\viewhtml78018dad9 to C:\Users\rempsyc\AppData\Local\Temp\Rtmpm6A9ju\Rbuild3da8687e3541\rempsyc\.Rproj.user\418BC976\viewer_history\viewhtml78018dad9: Permission denied
ERROR
copying to build directory failed
Error: System command 'Rcmd.exe' failed, exit status: 1, stdout & stderr were printed
Seems like it could be related to this change in 4.2.0 :
The default personal library on Windows, folder R\win-library\x.y where x.y stands for R release x.y.z, is now a subdirectory of local application data directory (usually a hidden directory C:\Users\username\AppData\Local).
I could not find any information on that sneaky rstudio.lock file online.
Btw, could you please also check the permissions on that file? E.g. if you are using multiple users or an administrator account to run RStudio, then maybe the lock file was created under that account, with restricted permissions.
All users have full permissions on both the lock file and the Temp folder. Note that the lock file is deleted and recreated everytime I close Rstudio for that particular package. So it is not possible to check permissions on it when Rstudio is closed since it doesn't exist in those conditions.
Rstudio says I'm using the latest version (Is that the "nightly build"?):
RStudio 2022.02.2+485 "Prairie Trillium" Release (8acbd38b0d4ca3c86c570cf4112a8180c48cc6fb, 2022-04-19) for Windows
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.12.8 Chrome/69.0.3497.128 Safari/537.36
However, here's a plot twist: the issue also emerges using the RGui in 4.2.0 (but not RGui 4.1.2 ), when Rstudio is closed and there is norstudio.lock file in the Temp directory. Perhaps the lock file was a potential false lead after all.
Based on this finding and someone's suggestion, I've cloned a clean version from GitHub and this has fortunately fixed the issue. So I'm not sure what the problem might have been, but it now works. Perhaps a simple corruption of the original package somehow?