项目文件夹

文件
wehub-resource-sync 26f897c1ec
release / release-please (push) Failing after 1m49s
docs / build (push) Failing after 6m34s
release / build-and-upload (arm64, linux) (push) Has been cancelled
release / build-and-upload (arm64, windows) (push) Has been cancelled
release / build-darwin (amd64, darwin) (push) Has been cancelled
release / checksums (push) Has been cancelled
release / finalize (push) Has been cancelled
release / build-darwin (arm64, darwin) (push) Has been cancelled
release / build-and-upload (amd64, linux) (push) Has been cancelled
release / build-and-upload (amd64, windows) (push) Has been cancelled
docs / deploy (push) Has been cancelled
chore: import upstream snapshot with attribution
2026-07-13 12:34:16 +08:00

34 行
1.1 KiB
Go

//go:build windows
package daemon
import (
"os"
"golang.org/x/sys/windows"
)
// lockByteOffset is where the single locked byte lives. Unlike flock,
// LockFileEx byte-range locks are mandatory: a lock overlapping the holder
// record at the start of the file would make readLockHolder's cross-handle
// ReadAt fail with ERROR_LOCK_VIOLATION, so the locked byte sits far past
// any data ever written to the file (range locks may extend beyond EOF).
const lockByteOffset = 0xFFFFFFFF
// tryLockFile takes a non-blocking exclusive lock on f via LockFileEx. Like
// flock on Unix, this lock is released by the OS when the owning process
// exits or crashes, so a held lock always means a still running holder.
func tryLockFile(f *os.File) error {
ol := &windows.Overlapped{Offset: lockByteOffset}
return windows.LockFileEx(
windows.Handle(f.Fd()),
windows.LOCKFILE_EXCLUSIVE_LOCK|windows.LOCKFILE_FAIL_IMMEDIATELY,
0, 1, 0, ol,
)
}
func unlockFile(f *os.File) error {
ol := &windows.Overlapped{Offset: lockByteOffset}
return windows.UnlockFileEx(windows.Handle(f.Fd()), 0, 1, 0, ol)
}