In this PR some lock handling logic has been removed from the core WOPI logic and delegated to the storage interfaces, in the assumption that the different CS3 storage providers do implement what is required:
getlock() of an expired lock returns None
refreshlock() and setlock() of an existing or expired lock behave as per CS3API specs
A lock is not any longer auto-extended based on the last save time from PutFile actions.
The xrootd interface has been adapted, but the detection of external locks now depends on the (EOS) storage to fail a setlock() operation when a flock exists on the file, as the wopiserver cannot tell any longer if a previously found LibreOffice lock is not owned by itself in the general case of no permissions in the folder (single-file share). Yet, the logic to inspect LibreOffice or MS Office lock files is kept in case permissions allow.
In this PR some lock handling logic has been removed from the core WOPI logic and delegated to the storage interfaces, in the assumption that the different CS3 storage providers do implement what is required:
getlock()of an expired lock returnsNonerefreshlock()andsetlock()of an existing or expired lock behave as per CS3API specsPutFileactions.The xrootd interface has been adapted, but the detection of external locks now depends on the (EOS) storage to fail a
setlock()operation when aflockexists on the file, as the wopiserver cannot tell any longer if a previously found LibreOffice lock is not owned by itself in the general case of no permissions in the folder (single-file share). Yet, the logic to inspect LibreOffice or MS Office lock files is kept in case permissions allow.For Reva, https://github.com/cs3org/reva/pull/2444 and https://github.com/cs3org/reva/pull/2625 are expected to be merged for this to work.