I did toy with the relative path consideration, but could never reproduce a situation where invocations from different working directories (hence, different relative paths, but the same absolute path) would result in different locks. If there's only one file that you're running, it's going to be the same thing being locked.

After all, the OS is supposed to resolve the paths to a file, probably a device ID and an inode on Unixes. So all ways to name the same file should end up with the same file.

I think there is a way to obtain two different locks on a single file. It is a very constructed example, and quite silly to use in the real world. The trick is to make the operating system on our machine think we would try to lock two different files.

Let's assume that locking "just works" over the net for every single protocol used below. In the real world, this is not always the case.

Let's put the file to be locked on a fileserver. Export the filesystem on which the file is stored via some protocol to our computer. Locking still works fine with this setup. Now, choose a second protocol to mount the same server filesystem again on a different mount point. Using only the second mount point, locking should still work fine.

Now, what happens when we use both mount points, i.e. both protocols, to try to lock our file?

Ideally, both protocol implementations would just transparently pass any locking request to the server's operating system. Nothing would change, except for some overhead, so only one process on our computer could obtain a lock.

But if at least one protocol implementations implement their own file locking mechanism, and we would try to lock the file using both mount points, neither of the protocol implementation would know about the other one's locks, and so two independent locks could be obtained for the same file.

The same construct should also work if one protocol is local filesystem access and the other one is a network protocol via the loopback interface that implements its own locking. It should also work with a user-space filesystem implementation (e.g. FUSE) that implements its own locking on top of a local filesystem in place of the network protocol via the loopback interface.

Alexander