Right now it's possible for a locker to unlock a lock it didn't actually create:
The solution we've come up with is to track the ctime of the parent and only delete the lock if the ctime of the parent matches what we thought it was.
The reason why this works is if the parent hasn't been deleted, the sequence numbers of the lock files will always be increasing.
implement the fix for #34
when lock path is created, we now cache the stat of the parent at that time,
allowing us to compare ctimes when we want to clean up. an unlock call on a
lock not owned by the current session will return false now.
update RELEASES file