The code tries to open the database directory directly and apply an exclusive lock to it:
Rust
let directory_lock = fallible!(fs::File::open(path));
fallible!(directory_lock.try_lock_exclusive());
On Windows, you cannot open or lock a directory like a regular file using standard file-locking mechanisms (it results in an AccessDenied or PermissionDenied error).
Proposed Fix:
Rust
const DIRECTORY_LOCK_FILE: &str = ".sled-directory-lock";
// ...
let file = OpenOptions::new()
.create(true)
.read(true)
.write(true)
.open(path.join(DIRECTORY_LOCK_FILE))?;
file.try_lock_exclusive()?;
Instead of locking the directory itself, it creates a hidden file (.sled-directory-lock) inside that directory and locks that. This is the industry-standard workaround used by major databases (like SQLite and RocksDB) to achieve cross-platform process locking.
Because Rust opens files on Windows with shared read/write access by default, a second process will successfully open the file handle but fail immediately at try_lock_exclusive(), correctly preventing concurrent database access.
I have it fixed in my fork, but i am disallowed to open a PR.
The code tries to open the database directory directly and apply an exclusive lock to it:
Rust
On Windows, you cannot open or lock a directory like a regular file using standard file-locking mechanisms (it results in an AccessDenied or PermissionDenied error).
Proposed Fix:
Instead of locking the directory itself, it creates a hidden file (
.sled-directory-lock) inside that directory and locks that. This is the industry-standard workaround used by major databases (like SQLite and RocksDB) to achieve cross-platform process locking.Because Rust opens files on Windows with shared read/write access by default, a second process will successfully open the file handle but fail immediately at
try_lock_exclusive(), correctly preventing concurrent database access.I have it fixed in my fork, but i am disallowed to open a PR.