Documentation ¶
Overview ¶
Package lockedfile creates and manipulates files whose contents should only change atomically.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Transform ¶ added in v1.10.0
Transform invokes t with the result of reading the named file, with its lock still held.
If t returns a nil error, Transform then writes the returned contents back to the file, making a best effort to preserve existing contents on error.
t must not modify the slice passed to it.
Types ¶
type File ¶
type File struct {
// contains filtered or unexported fields
}
A File is a locked *os.File.
Closing the file releases the lock.
If the program exits while a file is locked, the operating system releases the lock but may not do so promptly: callers must ensure that all locked files are closed before exiting.
func Edit ¶
Edit creates the named file with mode 0666 (before umask), but does not truncate existing contents.
If Edit succeeds, methods on the returned File can be used for I/O. The associated file descriptor has mode O_RDWR and the file is write-locked.
type Mutex ¶
type Mutex struct { Path string // The path to the well-known lock file. Must be non-empty. // contains filtered or unexported fields }
A Mutex provides mutual exclusion within and across processes by locking a well-known file. Such a file generally guards some other part of the filesystem: for example, a Mutex file in a directory might guard access to the entire tree rooted in that directory.
Mutex does not implement sync.Locker: unlike a sync.Mutex, a lockedfile.Mutex can fail to lock (e.g. if there is a permission error in the filesystem).
Like a sync.Mutex, a Mutex may be included as a field of a larger struct but must not be copied after first use. The Path field must be set before first use and must not be change thereafter.
func (*Mutex) Lock ¶
Lock attempts to lock the Mutex.
If successful, Lock returns a non-nil unlock function: it is provided as a return-value instead of a separate method to remind the caller to check the accompanying error. (See https://golang.org/issue/20803.)