Support for differences in OS and file system

[mike-ivs]

Currently the process mechanisms _interprocess_reader_writer_mechanism and _interprocess_mechanism are tied to os.name meaning the type of lock used is the same as the OS running python.

This is fine for the vast majority of use cases, however when accessing Windows shares on Unix machines (i.e. via cifs/samba mounts) fasteners attempts to unsuccessfully apply _Fcntl locks on these share files instead of the compatible _Windows locks.

Would it be possible to implement a fallback mechanism when locks cannot be acquired (threading.ThreadError "Unable to acquire a file lock") to attempt to create a lock using the alternate mechanism? i.e. if a windows lock fails attempt a fcntl lock, and vice versa?

Fallback variables could be defined in process_mechanism.py alongside the above interprocess functions :

_interprocess_reader_writer_mechanism = _FcntlInterProcessReaderWriterLockMechanism()
_interprocess_mechanism = _FcntlInterProcessMechanism()
_FALLBACK_interprocess_reader_writer_mechanism = _WindowsInterProcessReaderWriterLockMechanism()
_FALLBACK_interprocess_mechanism = _WindowsInterProcessMechanism()

which can then be used in process_lock.py as an additional layer of try:except to try before raising a ThreadError.

[psarka]

We can't use your suggestion - in order to create a "Windows" lock we use windows kernel (like this kernel32 = WinDLL('kernel32', use_last_error=True)). This will fail on an OS running python.

ChatGpt is telling me that

Yes, you can use fcntl and flock on Samba-mounted paths as if they were local Linux paths. Samba takes care of translating the file locking calls between the client and server. You don't need to modify the system calls when using them with a Samba share.

So I suppose this should be a bug rather than a feature request. If you have a stack trace at hand, could you post it here? :)

[mike-ivs]

Gah! Of course, not sure how I missed that when I had a look at the code. Thanks for your prompt reply.

Unfortunately I only have a (low-res) PNG of the stack trace as it comes second hand from someone else (png attached).

For context they were using the MDAnalysis package (2.4.3) which introduced filelocking in 2.2.0, which they have rolled back to as a work around for now. They are running MacOS and using CIFS UTIL to mount and access an SMB share.

More context: it sounds like their colleagues/students are using MDAnalysis 2.4.3 on Linux (ubuntu 2X.04) and are not encountering those issues, so perhaps this is a MacOS issue, or potentially a "local" issue not a fasteners/package issue.

[psarka]

Thanks!

I think there is nothing fasteners can do about it, but I opened a suggestion for improvement in the MDAnalysis repo. The user probably can't do anything either. ChatGPT is telling me that adding locking = yes option in the smb.conf file on the samba server could fix this, but I don't know if that's true, and user won't be able to do that anyway.