not locking based on extra dots in filename

[r2evans]

The correctness of locking is contingent on simple file patterns.

Side-by-side, two R processes on the same host, code executed from top to bottom in order.

system("uname -a") # ubuntu 23.10
# Linux d2xps 6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:59:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Sys.getpid()                                       Sys.getpid()
# [1] 278046                                       # [1] 195240

Correct behavior:

path <- "~/Downloads/quux.lock"                    path <- "~/Downloads/quux.lock"
lock <- filelock::lock(path, timeout=0)
lock
# Lock on ‘/home/r2/Downloads/quux.lock’
                                                   lock <- filelock::lock(path, timeout=0)
                                                   lock  
                                                   # NULL
filelock::unlock(lock)                             filelock::unlock(lock)
# [1] TRUE                                         # [1] TRUE

Same path, slightly different filename:

path <- "~/Downloads/quux.rds.lock"                path <- "~/Downloads/quux.rds.lock"
lock <- filelock::lock(path, timeout=0)
lock
# Lock on ‘/home/r2/Downloads/quux.rds.lock’
                                                   lock <- filelock::lock(path, timeout=0)
                                                   lock                                        
                                                   # Lock on ‘/home/r2/Downloads/quux.rds.lock’
filelock::unlock(lock)                             filelock::unlock(lock)
# [1] TRUE                                         # [1] TRUE

The underlying filesystem is local (/) and is ext4. R-4.3.2, filelock_1.0.3, in a single emacs/ess instance.

[gaborcsardi]

I cannot reproduce this, unfortunately.

[r2evans]

Interesting! I just tried using callr::r_bg and cannot reproduce it. My test above is in two processes within the same emacs/ess, do you think it's possible that somehow the process group or process-parent is confounding the logic?

[gaborcsardi]

No, the fnctl(2) manual page [1] does not say anything about locks being inherited or shared. (Although they might ignore forking a process without executing another, so if you're doing that that might explain this.)

It is also very weird that this would depend on the file name.

[1] https://man7.org/linux/man-pages/man2/fcntl.2.html

[r2evans]

I can't see anything in the source that would contribute to this behavior. Further ... odd ... I can no longer reproduce the behavior above. Further odd since I tested it a dozen times (same code) before starting this issue. :-/