Cryptographically verifiable, distributed dependency reviews
Add the last reviewed version to Cargo.toml / [dependencies]:
file-lock = "1.1.20"
Please, use mobile in landscape.
Filter reviews clicking on the numbers in the summary.
Full column names in tooltip hints: rating Negative, rating Neutral, rating Positive, rating Strong, thoroughness, understanding, reviews count.
© bestia.dev 2023, MIT License, Version: 2023.608.1636
Open source repository for this web app: https://github.com/bestia-dev/cargo_crev_web/
As the README claims, this locks files using the fcntl libc method, and it
provides locks for both read and write access. I've read the man pages for
that thoroughly and compared it to the implementation of this crate, and at
least the C part of it is nearly perfect. I would have named some things
differently, but aside of that, this part is good as it stands. It always
locks the whole file, uses the proper flags and in general looks good. As for
the rust part.. well, that's where the problems begin. The Drop impl does
unlock the file, but ignores the result of the unlocking (it calls .is_ok() on
the Result and ignores the return value, which is an antipattern also present
in all of the test cases). When aquiring an exclusive lock, it disables read
access to the file, causing bad fd errors when trying to read anyway. Last but
not least, this crate hasn't been updated for the 2018 edition, has tons of
warning and is using the deprecated and unmaintained gcc crate. These problems
are easily fixable, and where I'm using the crate, I'm using my fork which has
all these problems fixed, but considering that the other 3 MRs of the last
year haven't been fixed either, I have my doubts about this still being
maintained. If upstream continues to not respond, I'll fork this and update my
review with an alternative accordingly.