Currently the "add new files during scanning" call stack is smaller than
the "remove deleted files during scanning" call stack. This can lead to
the scanner adding folders in the folder tree that are to deep to be
removed.
This changes the `removeChildren` logic to be non recursive so there is
no limit to the depth of the folder tree during removal
Signed-off-by: Robin Appelman <robin@icewind.nl>
while this scan *should* never be triggered, it's good to have some failsafe to ensure
that the users home contents don't end up getting scanned in the root storage
Signed-off-by: Robin Appelman <robin@icewind.nl>
Currently you need to use `opendir` and then call `getMetadata` for
every file, which adds overhead because most storage backends already
get the metadata when doing the `opendir`.
While storagebackends can (and do) use caching to relief this problem,
this adds cache invalidation dificulties and only a limited number of
items are generally cached (to prevent memory usage exploding when
scanning large storages)
With this new methods storage backends can use the child metadata they
got from listing the folder to return metadata without having to keep
seperate caches.
Signed-off-by: Robin Appelman <robin@icewind.nl>
To continue this formatting madness, here's a tiny patch that adds
unified formatting for control structures like if and loops as well as
classes, their methods and anonymous functions. This basically forces
the constructs to start on the same line. This is not exactly what PSR2
wants, but I think we can have a few exceptions with "our" style. The
starting of braces on the same line is pracrically standard for our
code.
This also removes and empty lines from method/function bodies at the
beginning and end.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
This is done by adding a
```xml
<d:eq>
<d:prop>
<oc:owner-id/>
</d:prop>
<d:literal>$userId</d:literal>
</d:eq>
```
clause to the search query.
Searching by `owner-id` can only be done with the current user id
and the comparison can not be inside a `<d:not>` or `<d:or>` statement
Signed-off-by: Robin Appelman <robin@icewind.nl>
normally this shouldn't be a problem, but cache/storage desync might cause this
so this adds some failsafe to ensure we dont corrupt the cache further
the minimum value is set to -1 instead of 0 in order to triger a background scan
on the folder and figure out the size properly
Signed-off-by: Robin Appelman <robin@icewind.nl>
* Order the imports
* No leading slash on imports
* Empty line before namespace
* One line per import
* Empty after imports
* Emmpty line at bottom of file
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Fixes#15048
Catches the case where a full mimetype is sumbitted in the where like
clause. Before we didn't catch this and it was just forwarded as is
causing invalid queries.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Christoph Wurst
Roeland Jago Douma
Morris Jobke
Robin Appelman
Joas Schilling
tobiasKaminsky
Roeland Jago Douma
Arthur Schiwon