----- BEGIN CREV PROOF -----
kind: package review
version: -1
date: "2021-05-21T14:00:32.881465652+02:00"
from:
  id-type: crev
  id: YdnEoYtqvbBGv0hhENLDUYmc3tNfm5V5NIG5hCovHyM
  url: "https://git.jcg.re/jcgruenhage/crev-proofs.git"
package:
  source: "https://crates.io"
  name: file-lock
  version: 1.1.20
  digest: Av61358dytJkb_iBCTZzy-0J868RHCPLC1wgQ6o_VXk
review:
  thoroughness: high
  understanding: high
  rating: neutral
flags:
  unmaintained: true
comment: |-
  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.
----- SIGN CREV PROOF -----
OsHzghhizKAFsZbIfwU1WjgLl5waAl17bAkB7JRF7q7Z72YKs6PMuVq400SS25Jc4lO1rgwUSmCVGfKBofe9AQ
----- END CREV PROOF -----