-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix/dav #2608
Fix/dav #2608
Conversation
@max-nextcloud can we then also have a test, so this regression cannot happen again? :) |
@vinicius73 why was master merged in this branch? |
This branch has master as target, we can't merge it properly without update it. |
we should do rebasing instead then instead of creating merge commits, always a bit cleaner |
👍 "add folder info" works again. |
One problem I now see is:
--> if requested, the folder and its children should always have the rich workspace property properly set |
The CI failures are indicating that names other than 'Readme.md' - i.e. 'README.md' or 'Anleitung.md' do not work anymore for the rich workspaces in the web ui. This used to be server side logic in the I'm not a big fan of supporting translated or all caps readme file names - but it's what we did in the past so breaking it does not seem like a good idea either. |
@CarlSchwan Sounds like you've been using curl to test this... Could you share your curl commands so i can base the tests on it? |
02da266
to
35bc87d
Compare
Added tests and fixed issues that the reverted commit had fixed. The workspace property is still not set for nested folders (see #2608 (comment)). I think in order to bring that back we need to revert be562a4. |
21f21f4
to
1bbef41
Compare
|
2a369ea
to
c24534a
Compare
@tobiasKaminsky I think this should fix both issues now. Also added regression tests |
lib/DAV/WorkspacePlugin.php
Outdated
if ($propFind->getDepth() === $this->server->getHTTPDepth()) { | ||
$propFind->handle(self::WORKSPACE_PROPERTY, function () use ($node) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not entirely sure about removing this condition. #2608 (comment) sounds like workspace needs to be set for nested folders and we rely on it being set in our new tests for depth=0.
My understanding is that this will only be evaluated anyway if the property is requested. Would like to hear @juliushaertl opinion on this before a merge though.
Looks good 👍👍👍 |
I found a strange bug?
Use Insomnia/cURL to show rich-workspaces property of /1/ folder -> see nothing |
What is missing here? |
This PR reverts a change that was introduces as a performance fix. We need to evaluate the impact of undoing that fix. (See #2608 (review) for the code in question) |
👍 I hope this will be possible before the first RC of 24.0.3... |
So i profiled this some. Profiling Commandfor n in {1..10} ; do curl -w "%{time_total}\n" -o /dev/null -s 'http://nextcloud.local/remote.php/dav/files/admin/' -X PROPFIND -u admin:admin --data '<?xml version="1.0"?>
<d:propfind xmlns:d="DAV:" xmlns:oc="http://owncloud.org/ns" xmlns:nc="http://nextcloud.org/ns" xmlns:ocs="http://open-collaboration-services.org/ns">
<d:prop>
<d:getlastmodified />
<d:getetag />
<d:resourcetype />
<oc:fileid />
<nc:file-metadata-size /><oc:permissions />
<oc:size />
<d:getcontentlength />
<d:quota-available-bytes />
<nc:rich-workspace /> <nc:rich-workspace-file /> <nc:has-preview />
<nc:mount-type />
<nc:is-encrypted />
<ocs:share-permissions />
<oc:tags />
<oc:favorite />
<oc:owner-id />
<oc:owner-display-name />
<oc:share-types />
<oc:comments-unread />
</d:prop>
</d:propfind>'; done | LC_ALL=C awk '{ total += $1; count++ } END { print total/count }' 22 Folders inside root folder of admin:
222 Folders inside root folder of admin:
|
@tobiasKaminsky Can you maybe clarify on how the android client is requesting the workspaces especially in regards to the Depth value? From #994 we had issues in the past with large folder structures that is why the response was limited to only return the workspace on the requested root node. |
@juliushaertl initial bug fix works, what we discussed yesterday! But this one still happens:
|
@tobiasKaminsky I could reproduce but seems related to the files_lock app. Do you have that one enabled in your test instance? I'd consider that a separate bug then. |
I have, yes. |
Should be fixed on master already with nextcloud/files_lock#75 but I have a follow up patch in the pipeline that I worked on with @max-nextcloud now. |
This reverts commit 3e40b7b. Signed-off-by: Carl Schwan <[email protected]>
Otherwise if the Depth header is ommited, the workspace information won't be display at all. Signed-off-by: Carl Schwan <[email protected]>
Regression tests for nextcloud/server#32514 (comment) Signed-off-by: Max <[email protected]>
These fixes were lost when reverting 3e40b7b. Signed-off-by: Max <[email protected]>
Signed-off-by: Max <[email protected]>
Signed-off-by: Julius Härtl <[email protected]>
I profiled this and it actually improves performance. With 222 folders i get:
This is still fairly slow and also applies when loading the files list in the browser. On the other hand this is the expected behavior by the client. We will either need to add some caching or make more specific requests on the client (one depth 0 I approved this and will merge as it fixes the bug in question. |
/backport to stable24 |
Summary
Clients expects this behavior:
If rich-workspaces is enabled and readme.md is empty or does not exist, it must return "".
If disabled -> null.
If readme.md has content -> show content
This revert to it and also make it possible in a separate commit to not have to add 'Depth: 1' in the curl request to get the workspace information