In all versions up to 0.9.1, LockBase sets unique_name to:

os.path.join(dirname,"%s.%s%s" % (self.hostname,tname,self.pid))

Doesn't this mean you can't have two lockfiles in the same directory for the same process/thread? Is that by design? If not, it seems like it might be useful to change this name or the conditionals that check for a lock so that multiple lock files could exist in the same directory.

I can confirm that this indeed is a serious defect in at least one real life scenario. What's worst, lockfile doesn't error when a file named unique_name already exists, giving spurious and hard to understand NotMyLock exceptions later on.

I have made a fix for this issue and created a GitHub pull request: https://github.com/smontanaro/pylockfile/pull/2

keen on seeing the fix in the main repository and pypi :)

I'm sorry, but I can't accept this pull request. It includes feature changes other than the bug fix, has no changes to the test suite, and includes fixes for other bugs which I have already fixed.

I will work on my own fix. Can you provide a simple test case that demonstrates the problem you want fixed? It seems just as likely that your code is buggy if you want to lock the same file more than once from the same thread (or process, in the single-threaded case).

I withdrew the old pull request and submitted a new one, a feature branch this time.

Simple test case? have two files in the same directory. Lock both, then unlock both. During the second unlock, pylockfile used to fail.