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

[tclose]

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?