summaryrefslogtreecommitdiff
path: root/crates/fslock-guard
Commit message (Collapse)AuthorAgeFilesLines
* Bump patchlevel of crates with functional changes.Gabriela Moldovan2024-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | Functional changes were made, but no APIs were added or broken: ``` tor-events (async_broadcast 0.6.0 -> 0.7.0) tor-netdoc (signature 1 -> 2) tor-guardmgr arti-testing (config 0.13.4 -> 0.14.0) tor-persist (breaking changes gated behind experimental feature) fslock-guard (fix lockfile_has_path compilation on Windows) ``` Done with: ``` cargo set-version --bump patch -p tor-events cargo set-version --bump patch -p tor-netdoc cargo set-version --bump patch -p tor-guardmgr cargo set-version --bump patch -p arti-testing cargo set-version --bump patch -p tor-persist cargo set-version --bump patch -p fslock-guard ```
* fslock-guard: Fix Windows compilationTobias Stoeckmann2024-03-011-2/+2
| | | | | Cast argument to GetFileInformationByHandle, because types do not match. Output is: expected `winapi::ctypes::c_void`, found `std::ffi::c_void`
* Bump minor versionsIan Jackson2024-02-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bump the minor version of these crates, and update the in-tree dependencies. Recently published as fresh crates, let's just assume there are breaking changes: fslock-guard test-temp-dir Breaking API change affecting many many downstream crates: tor-rtcompat Downstream crates which we're (conservatively) assuming have tor-rtcompat types in their APIs: tor-rtmock tor-log-ratelim tor-rpcbase tor-llcrypto tor-protover tor-bytes tor-hscrypto tor-hspow tor-socksproto tor-checkable tor-cert tor-linkspec tor-cell tor-proto tor-netdoc tor-consdiff tor-netdir tor-congestion tor-persist tor-chanmgr tor-ptmgr tor-guardmgr tor-circmgr tor-dirclient tor-dirmgr tor-keymgr tor-hsclient tor-hsservice tor-hsrproxy arti-client arti-rpcserver arti-config arti-hyper arti-bench arti-testing
* fslock-guard: Add links to documentation about windows approachNick Mathewson2024-01-241-0/+7
|
* fslock-guard: use winapi to test file-equivalency on windowsNick Mathewson2024-01-232-6/+22
|
* fslockguard: try to document windows assumptionsNick Mathewson2024-01-231-0/+41
| | | | | These are necessarily a bit hand-wavey, but I think they summarize what we are assuming.
* Remove an XXX: fslock does indeed use O_CLOEXEC.Nick Mathewson2024-01-231-1/+0
|
* fslockguard: implement a delete_lock_file function.Nick Mathewson2024-01-232-3/+30
|
* Use fslock-arti-forkNick Mathewson2024-01-232-20/+7
|
* fslock-guard: Write down the locking protocol on UnixIan Jackson2024-01-231-0/+65
| | | | | | Text from here https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1900#note_2986683 with a few minor fixes.
* fslock-guard: Rename os modulesIan Jackson2024-01-231-2/+2
| | | | | | | | | | | These two modules are key to the implementation of the locking protocols. We must define the locking protocol in terms of underlying OS semantics (since Unix and Windows have different fs concepts and different concurrency semantics) and therefore, although we are sharing some code between the implementations, these modules are what defines the two protocols.
* Give a formal semantics for the fslock operations.Ian Jackson2024-01-221-0/+15
|
* fslock-guard: sketch implementationNick Mathewson2024-01-213-0/+188
This is not yet "correct", since it will rely on https://github.com/brunoczim/fslock/pull/15 (Conceivably, it might be better to make the `fslock` crate rm-safe.)