Lock file permission issues

[pydupont]

Hello,

On a Linux machine if a user runs a drake pipeline, the same pipeline can't be run again (or the results checked) by another user. The following error occurs:

Error in filelock::lock(private$lock_file) : 
  Cannot open lock file: Permission denied
Error in filelock::unlock(lock) : 
  VECTOR_ELT() can only be applied to a 'list', not a 'closure'

If the file .drake/drake/history/lock is removed manually, the second user can use the pipeline again.

Is there a way to unlock the pipeline from R?
I used the option lock_envir = FALSE in the make function but the problem is still occurring.

I am using drake v7.7.0.9002 with R3.5.1

Is this the same issue as #1232? I would prefer to keep the history, so do I have a solution that doesn't require me setting history = FALSE.
Shouldn't the lock file be removed if the pipeline is finished?

Kindly,

Pierre

[wlandau]

Yes, it is the same issue as #1232. Unfortunately, the best I can recommend is to remove the lockfile or disable history. Maybe this should be addressed in the filelock package itself.

[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.

[pydupont]

None of the two txtq commits solved the problem. I also updated drake to the last version on github but still no success. I will have a look at filelock.
Cheers

[pydupont]

Would it be possible to change the permissions on the lock file using:

Sys.chmod(".drake/drake/history/lock", "660", use_umask = FALSE)

So that people from the same user group can use the lock file too?

[wlandau]

Possible, yes, but not something I am likely to do in drake itself. I recommend invoking it in your script(s) that invoke drake, and posting an issue to filelock if you can reproduce the issue without drake or txtq.

[wlandau]

drake does not actually need txtq to have a lock file because only the master process modifies history. So #1232 will probably open up a better solution.

[wlandau]

Closing again due to wlandau/txtq#18 (comment). Sorry to have gotten your hopes up.

[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.

[pydupont]

It works! Thanks for your work!

[wlandau]

Thanks for confirming.