Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stale lockfile encountered in the wild #1011

Closed
Shnatsel opened this issue Sep 21, 2023 · 2 comments · Fixed by EmbarkStudios/tame-index#33 or #1032
Closed

Stale lockfile encountered in the wild #1011

Shnatsel opened this issue Sep 21, 2023 · 2 comments · Fixed by EmbarkStudios/tame-index#33 or #1032

Comments

@Shnatsel
Copy link
Member

Reported at Byron/gitoxide#1026

@Shnatsel
Copy link
Member Author

The locking implemented by gix is broken by design; we will likely need to roll our own, and also update tame-index to use proper locking. I've opened an issue for tame-index as well: EmbarkStudios/tame-index#30

Jake-Shadle added a commit to EmbarkStudios/tame-index that referenced this issue Sep 29, 2023
As pointed out in #30, gix's locking mechanism is insufficient in the
face of SIGKILL or other process interruption that can't be caught by
gix's signal handler, in addition to the giant footgun that tame-index
doesn't actually hook that signal handler for you, meaning applications
using it that forget to hook it also run into issues.

In addition, I raised #17 while doing
crate-ci/cargo-release#693
(https://github.com/crate-ci/cargo-release/pull/693/files/012d3e9a7be23db14096e6a0d41cea7528f9348c#r1301688472)
as right now tame-index can perform mutation concurrently with cargo
itself, or potentially read partial data while it is being written.

This PR resolves both of these issues by forcing all R/W operations on
indexes to take a `&FileLock` argument, as well as providing a
`LockOptions` "builder" to create file locks. These locks are created
using flock on unix and LockFileEx on windows, meaning they can properly
be cleaned up by the OS in all situations, including SIGKILL and power
loss etc, unlike gix's locks, and is the same mechanism that cargo uses
for its global package lock, meaning downstream users can ensure they
play nicely with cargo.

The lock facilities are part of the public API of tame-index as I opted
to roll my own implementation instead of using fslock, as it is very
outdated, and doesn't support timeouts. This does mean a lot of unsafe
has been added, but it is tested and not _too_ bad. This can potentially
be moved out to a separate crate in the future, but is fine for now.
This means it could be used to resolve
rustsec/rustsec#1011, and is something I will
use in cargo-deny for the same thing, protecting access to the advisory
database during mutation.

It should also be noted that one can also just construct a
`FileLock::unlocked()` to satisfy the API, without actually performing
any locking, for cases where it's not needed/testing/etc.

Resolves: #17
Resolves: #30
@Shnatsel
Copy link
Member Author

tame-index has added OS locking support in EmbarkStudios/tame-index#33, we can now use its locking implementation to fix this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant