drake/lock permissions

[danwwilson]

Prework

• Read and abide by drake's code of conduct.
• Search for duplicates among the existing issues, both open and closed.

Description

When creating a new drake project that is stored on a network drive the .drake/drake/history/lock file doesn't have group read permissions. This tends to cause issues for backup jobs (run under a backup user), as it isn't able to read the lock file.

What it means for me personally is needing to adjust the permissions for the lock file for each new drake project. While it's not a deal breaker, I was wondering if there might be something in the way that use_drake() creates objects that might allow the read permissions for the group to be applied.

[wlandau]

use_drake() actually just creates script files. The cache gets created when you run make(), new_cache() or drake_config(). If you do not need drake_history(), you can set history = FALSE in make() or drake_config() to prevent history/lock from being generated at all. All the files in history/ are a txtq, and the lock file is generated by filelock. It will probably be easier on your end to troubleshoot similar issues with only those lighter packages.

[wlandau]

You could also try and install wlandau/txtq@ba15026. That commit forces txtq to remove the lockfile periodically. It should solve this issue except if the drake session crashes at the wrong time and does not clean up.

[wlandau]

Hmm... that turns out to not work on Windows for some reason. Try wlandau/txtq@4bf8876. In that commit, the lockfile is created in advance and outside filelock, which just might resolve permissions issues. I don't know.

[wlandau]

From r-lib/filelock#26, it looks like this error came from the fact that some file systems do not support file locking. Should be fixed for drake in 2ffd42a. Feel free to give it a try.