What happens if another type of OSError is raised when attempting to create a soft lock?

[Tom Close]

I ran into a strange bug when trying to lock a file on a network file-system mounted inside a container, where the lock file was created but for some reason it seems as though the file-handle wasn't properly returned. My process then got stuck waiting for the lock to be released (when it had in fact created the lock). Looking at the following code, it seems that if the OSError errno isn't EEXIST, ENOENT or EACCES, then it is assumed the file is locked

https://github.com/tox-dev/py-filelock/blob/4730a40b87cc4b094330b2af7723658428323d60/src/filelock/_soft.py#L23-L32

wouldn't it be more robust to do something like

 try: 
     fd = os.open(self._lock_file, mode) 
 except OSError as exception: 
     if (exception.errno == EEXIST # expected if cannot lock 
             or (if exception.errno == EACCES and sys.platform == "win32"):  # note windows does not allow you to make a folder r/o only files 
         pass 
     else:
         raise

Or do you actually want the code to keep attempting to try creating the lock on other OSErrors?

[Matthew Schweiss]

Related to #67

I agree I think it would be better to make sure unknown errors propagate, instead of causing an infinite loop.
I found another situation where this becomes a problem.

On Windows, if the name of the file given is invalid, such as forgetting to to double backspace on windows, the EINVAL message is not accounted for in the error handling.

import filelock

filename = "C:\path\to\lock\but\backslash\is\not\escaped"
with filelock.filelock(filename):
    pass # waits forever and never completes

If you had just tried to open the file, you would see the following message

filename = "C:\path\to\lock\but\backslash\is\not\escaped"
f = open(filename)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument: 'C:\\path\to\\lock\x08ut\x08ackslash\\is\not\\escaped'

[Bernát Gábor]

PR welcome 😁