-
Notifications
You must be signed in to change notification settings - Fork 130
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
The locking implemented by |
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
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reported at Byron/gitoxide#1026
The text was updated successfully, but these errors were encountered: