Print path to lock file that cannot be opened

[gadenbuie]

At some point I interrupted a running pak::pkg_install() and thereafter I occasionally get this error when I try to install a package that was part of the interrupted package install:

pak::pkg_install("usethis")                                               
#> → Will install 1 package.
#> → The package (705.78 kB) is cached.
#> + usethis   2.0.0 
#> ℹ No downloads are needed, 1 pkg (705.78 kB) is cached
#> Error: Cannot open lock file: Permission denied                     
#> Type .Last.error.trace to see where the error occured

The lock file is hard to find, and options(error = recover) isn't helpful since the error originates in a callr call. It would be helpful to print the path to the lock file so that the user can debug and/or remove the file.

I was able to use the library path returned from pak::pak_sitrep()

pak::pak_sitrep()
#> * pak version:
#> - 0.1.2.9001
#> * Version information:
#> - pak platform: x86_64-apple-darwin17.0 (current: x86_64-apple-darwin17.0, compatible)
#> - pak sha: 1e7825d149591ac548169c4a56dc18b214189da2
#> * Optional packages installed:
#> - tibble
#> * Library path:
#> - /Library/Frameworks/R.framework/Versions/4.0/Resources/library
#> * Private library is embedded.

to find (and delete) the usethis.lock file.

fs::dir_ls(
  "/Library/Frameworks/R.framework/Versions/4.0/Resources/library", 
  recurse = TRUE,
  regexp = "usethis.+lock$"
)
#> /Library/Frameworks/R.framework/Versions/4.0/Resources/library/_cache/usethis.lock
fs::file_delete(.Last.value)

After removing the bad lock file, usethis installed cleanly.

pak::pkg_install("usethis")                                     
#> → Will install 1 package.
#> → The package (705.78 kB) is cached.
#> + usethis   2.0.0 
#> ℹ No downloads are needed, 1 pkg (705.78 kB) is cached
#> ✓ Installed usethis 2.0.0  (56ms)                                   
#> ✓ 1 + 32 pkgs | kept 26, updated 0, new 1 | downloaded 0 (0 B) 815ms

[gaborcsardi]

Weird. In theory this is only possible if you stop a process during installation, and then start another process to install the same package.

Leftover lock files do not matter for filelock, which uses proper advisory locking, instead of just creating a lock file.

If you are sure that there were no install process (stopped or frozen) still running in the background, then this must be a bug.

[gadenbuie]

Oh yeah, I interrupted the usethis install two or three weeks ago (which is to say I'm fairly certain there isn't a process running in the background).

[gaborcsardi]

Then maybe you used an older version of pak back then, because this was fixed here: r-lib/pkgdepends@8b2feff

If this comes up again, or you can reproduce it, then I will investigate. :)

[gaborcsardi]

I have a guess what this might have been. You maybe did the interrupted installation as root or in sudo, or a different user, and then the new process did not have permissions to open (create, really) the lock file, because _cache was created by the other user.

[gadenbuie]

You maybe did the interrupted installation as root or in sudo, or a different user

This definitely wasn't the case. I had installed pak on 2020-12-01, so I thought maybe it would have been fixed by updating to the latest pak, as you mentioned above. Unfortunately, I still get the same errors (this time while trying to install crul):

pak::pkg_install("crul")
                                                                          
#> → Will install 1 package.
#> → Will download 1 CRAN package (622.06 kB).
#> + crul   1.0.0  ⬇ (622.06 kB)
#> ℹ Getting 1 pkg (622.06 kB)
#> ✓ Got crul 1.0.0 (macos) (622.06 kB)                              
#> ✓ Downloaded 1 package (622.06 kB) in 451ms                         
#> Error: Cannot open lock file: Permission denied              
#> Type .Last.error.trace to see where the error occured

pak::pak_sitrep()
#> * pak version:
#> - 0.1.2.9001
#> * Version information:
#> - pak platform: x86_64-apple-darwin17.0 (current: x86_64-apple-darwin17.0, compatible)
#> - pak sha: c140b09d8cdb3358ba8149e14a0ed326d4407be1
#> * Optional packages installed:
#> - tibble
#> * Library path:
#> - /Library/Frameworks/R.framework/Versions/4.0/Resources/library
#> * Private library is embedded.
pak::pak_update()
#> 
#> Current version is the latest, no need to update.
pak::pak_setup()
#> Private library is embedded, pak is ready to go.

[gaborcsardi]

#> Error: Cannot open lock file: Permission denied              

This definitely seems like a permission issue. Can you list the permissions of your library, and also _cache in it? I.e.

/Library/Frameworks/R.framework/Versions/4.0/Resources/library
/Library/Frameworks/R.framework/Versions/4.0/Resources/library/_cache

etc.

[gadenbuie]

You're right, this was a permissions issue. I don't remember running R or pak via sudo, but there were a number of folders in /Library/Frameworks/R.framework/Versions/4.0/Resources/library that were owned by root. Fixing the owner if all files in 4.0/Resources/library/ with chown -R solved my problem. Thanks for your help with this!

To circle back to my original request, I still think that it would be helpful to let the user know which lock file couldn't be opened. It took me quite a while to track down the lock file, and it felt like a shot in the dark when I did.

[gaborcsardi]

Yeah, it makes sense to print the path: r-lib/filelock#30