Push lock handling logic to storage interfaces #69
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…PI logic itself, not by the storage layers" Eventually we want to have the storage layers implement this logic, not WOPI This reverts commit 02f7072.
glpatcern
force-pushed
the
locking
branch
4 times, most recently
from
8540c31
to
3c6610c
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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, cs3org/reva#2444 and cs3org/reva#2625 are expected to be merged for this to work.