Open brunoczim opened 2 years ago
It seems like we could have some control over other LockFile
s, but not on other APIs, such as std::fs
.
Perhaps we could use flock
?
The problem is that is seems to be non-POSIX. However, libc
exports it unconditionally.
I'm likely publishing a new version of this library with flock
instead of lockf
. However, I'd like to mature this idea before.
Is 'flock` not-by-process in every platform? Or is it just Linux and MacOS?
Does libc
supported platforms really support flock
?
lockf
is POSIX compliant and works on NFS, see https://gavv.github.io/articles/file-locks/#lockf-function
Yeah, but lockf
has this "per-process issue", where I lock the file "foo" with one FD and loses it because someone else in the same process closed the same file but with another (unrelated) FD.
I intend to replace lockf
by flock
because flock
does not seem to have such problem.
What makes me think twice about flock
is that it's not POSIX, but rather implemented by quite a few Unix-like systems (like Linux, BSDs, MacOS, etc).
But yeah as I said earlier, libc
crate exposes flock
unconditionally for Unix targets. So, I believe flock
is supported by all Unix targets supported by Rust. I am likely using it.
I don't know this stuff too well to contribute much to the discussion, but while searching for Rust crates I did come across a resource on the topic that might be helpful for this issue/decision.
Maybe you've already seen it? :sweatsmile: (EDIT: I'm only now looking over the earlier link (https://gavv.github.io/articles/file-locks/#lockf-function) and noticing it covers similar details pretty well, so the information below probably doesn't contribute much, apologies!_)
Test
other_process_but_curr_reads
fails.It attempts to read the locked file into a string (in the same process, with
std::fs::read_to_string
) and then spawns another process to make it try to lock the file. It would be expected that the process would fail to lock, but it actually succeeds.I've made other tests, and without opening the file again and reading it, the lock works. I believe the bug is not in reading nor opening, but closing the file.
Manual page for
lock
seems to specify that it is implemented on top offnctl
on Linux. Also, manual page forclose
seems to specify thatclose
will revoke any locks viafnctl
on the file, no matter if a different FD to that file was closed.