using a Unix domain socket is implementation dependent. Buffered I/O problems One source of lock failure occurs when buffered I/O has buffers assigned in the user's local workspace, rather than in an operating system buffer pool. fread and fwrite are commonly used to do buffered I/O, and once a section of a file is read, another attempt to read that same section will, most likely, obtain the data from the local buffer. The problem is another user attached to the same file has their own local buffers, and the same thing is happening for them. An fwrite of data obtained from the buffer by fread will not be obtaining the data from the file itself, and some other user could have changed it. Both could use flock to ensure exclusive access, which prevents simultaneous writes, but since the reads are reading from the buffer and not the file itself, any data changed by user #1 can be lost by user #2 (over-written). The best solution to this problem is to use unbuffered I/O (read and write) with flock, which also means using lseek instead of fseek and ftell. Of course, you'll have to make adjustments for function parameters and results returned. Generally speaking, buffered I/O is unsafe when used with shared files. In AmigaOS In AmigaOS, a lock on a file (or directory) can be acquired using the Lock function (in the dos.library). A lock can be shared (other processes can read the file/directory, but can't modify or delete it), or exclusive so that only the process which successfully acquires the lock can access or modify the object. The lock is on the whole object and not part of it. The lock must be released with the UnLock function: unlike in Unix, the operating system does not implicitly unlock the object when the process terminates. Lock files Shell scripts and other programs often use a strategy similar to the use of file locking: creation of lock files, which are files whose contents are irrelevant (although often one will find the process identifier of the holder of the lock in the file) and whose sole purpose is to signal by their presence that some resource is locked. A lock file is often the best approach if the resource to be controlled is not a regular file at all, so using methods for locking files does not apply. For example, a lock